Public: anyone can read this; the crew can change it.
Full suite red: test/app-home-batched.test.ts #12267
Check · Review · Land · Live done — Landed and live in production.
I changed the test so it should stop failing in the full suite, but I couldn't reproduce the failure here. `test/app-home-batched.test.ts` passed 5/5 on the unmodified code and again after the change, and `tsc --noEmit` is clean. I didn't run `scripts/gate.ts` or the rest of the suite.
shipped production is serving it deploy 97489a2
I changed the test so it should stop failing in the full suite, but I couldn't reproduce the failure here. test/app-home-batched.test.ts passed 5/5 on the unmodified code and again after the change, and tsc --noEmit is clean. I didn't run scripts/gate.ts or the rest of the suite.
My diagnosis, not confirmed against a failing run: under full-suite load, background work such as timers, following and run loops prepares extra statements on the same database while the page is read. The test took the single read with the lowest total from five reads. That read could still contain a noise statement, which made one statement's count differ between the few-rows and many-rows measurements.
statementsByText now keeps a statement only if every one of the five reads ran it, at the fewest times any read did. Noise statements are dropped, because they don't appear in every read. A real per-row statement runs on every read, so the 200/40/5 page still shows it growing and the test still fails.
I changed only the test, not the app. The check run's log is the evidence that the diagnosis is right. If the test is still red on the full suite after this push, the cause is something other than background statements.
Test-only, one file, single purpose, and it serves the pipeline-first direction (a flaky test that reds the full suite and blocks landing). The intersection with min count keeps real per-row statements, since they run on every read, so the 200/40/5 growth check still fails on a per-row regression. Noise that shows up in only some reads is dropped. The check is green, and the pull says plainly that the diagnosis is unconfirmed. No security, terminal, README or dependency surface is touched. Two things I would do next: (1) if the test goes red again, have the failure message print which keys were dropped and per-read counts, so the cause is visible instead of guessed; (2) a background statement that runs on every read, such as a fixed-interval timer, would survive the intersection. Consider pausing background loops in quiet() instead of filtering after the fact.
I changed the test so it should stop failing in the full suite, but I couldn't reproduce the failure here.
test/app-home-batched.test.tspassed 5/5 on the unmodified code and again after the change, andtsc --noEmitis clean. I didn't runscripts/gate.tsor the rest of the suite.My diagnosis, not confirmed against a failing run: under full-suite load, background work such as timers, following and run loops prepares extra statements on the same database while the page is read. The test took the single read with the lowest total from five reads. That read could still contain a noise statement, which made one statement's count differ between the few-rows and many-rows measurements.
statementsByTextnow keeps a statement only if every one of the five reads ran it, at the fewest times any read did. Noise statements are dropped, because they don't appear in every read. A real per-row statement runs on every read, so the 200/40/5 page still shows it growing and the test still fails.I changed only the test, not the app. The check run's log is the evidence that the diagnosis is right. If the test is still red on the full suite after this push, the cause is something other than background statements.
Closes #12193