Flaky or data-dependent: the card page issues one more query on its second measure (query_counts_spec:103) #429

Seen. 2026-11-14 (UTC), GitHub CI on main at b9da192e (the merge of #424, a documentation-only change), run 43549766510, RSpec (2/4), seed 51048: 1383 examples, 1 failure.

spec/requests/query_counts_spec.rb:103, "Page query counts keeps the card page's queries independent of the number of lots": at line 111, expected: 19, got: 20.

The runs on the commits either side passed (c15a465c before, b89ff310 after), and no worker's branch has hit it.

What is known.

• The example measures the card page's query count twice inside itself: once with one lot of another printing (few), then again after adding 7 lots of the page's printing and 7 foil lots of another, and expects the same count. So the extra query is on the second request of one example, not a count compared across examples.
• queries_for leaves out cached, SCHEMA and TRANSACTION statements, so it is a real query.
• The file alone passes on main with seed 51048 and with seeds 1, 2 and 3, with and without CI=true (18 examples, 0 failures each).
• The session's daily stamp (Session::STAMP_INTERVAL, one day) was checked and doesn't fit: the session is seconds old.

Reading (not confirmed). It depends on what ran before it in the process. The likeliest carrier is factory state: a sequence value reached only after many earlier examples puts one of the 14 added lots, or its printing, on a branch that costs the page one more query (#213 was a failure of that kind, a sequence reaching 777, in another file). A cache warmed by an earlier example would lower the second count, not raise it.

To do. Reproduce first: replay the shard as CI ran it, on a checkout of b9da192e (SEED=51048 bin/ci rspec 2/4 prints the exact bin/rspec --seed … <files> command; the file list depends on the tree, so use that commit), then bisect the file list with bin/rspec --bisect to the example that sets it up. Log the SQL of both requests in the failing order and name the extra statement. Then decide from the evidence whether the page really issues a query that grows with some data (a product defect: an N+1 on a branch the factories rarely reach) or the example's setup is at fault. Record further sightings here (run, shard, seed).

Generated by Claude Code