Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:20ibtnaoxb is past its budget: trevato/forge: "now reads its rows in batches with 200 open issues, 40 open pulls and 5 active runs" failed on 3 pulls … #6816

I changed test/app-home-batched.test.ts so it counts SQL statements instead of timing the page. Load on the check machine can no longer fail it. Both tests in the file pass, and tsc --noEmit is clean. I haven't seen the forge's own check on the push yet.

Why it was red: the test asserted that the server-timing now phase took under 5 ms. expectBudget stretches that limit to at most 20 ms, and the limit scales with a /healthz baseline. On a busy check machine, scheduling noise alone could exceed 20 ms, so the verdict depended on load.

What changed:

• A new queriesFor(path) helper wraps app.db.query for one signed-in GET and returns how many statements it prepared.
• Both tests warm the page once, then assert the count is under 200. Today a page costs about 165 statements on /alice/vault and about 125 on /alice/vault-fork. A loop that ran one statement per issue would add roughly 200 more and fail.
• I dropped the unused budget.ts import from this test.

What I left out:

• The test no longer measures speed. The baselineMs/expectBudget helpers are still used by other tests, and I didn't audit those for the same problem.
• The 200 ceiling catches a per-row query loop, not a small regression such as a few extra statements.

To try it: bun test test/app-home-batched.test.ts

Closes #6815

I changed test/app-home-batched.test.ts so it counts SQL statements instead of timing the page. Load on the check machine can no longer fail it. Both tests in the file pass, and tsc --noEmit is clean. I haven't seen the forge's own check on the push yet.

Why it was red: the test asserted that the server-timing now phase took under 5 ms. expectBudget stretches that limit to at most 20 ms, and the limit scales with a /healthz baseline. On a busy check machine, scheduling noise alone could exceed 20 ms, so the verdict depended on load.

What changed:

• A new queriesFor(path) helper wraps app.db.query for one signed-in GET and returns how many statements it prepared.
• Both tests warm the page once, then assert the count is under 200. Today a page costs about 165 statements on /alice/vault and about 125 on /alice/vault-fork. A loop that ran one statement per issue would add roughly 200 more and fail.
• I dropped the unused budget.ts import from this test.

What I left out:

• The test no longer measures speed. The baselineMs/expectBudget helpers are still used by other tests, and I didn't audit those for the same problem.
• The 200 ceiling catches a per-row query loop, not a small regression such as a few extra statements.

To try it: bun test test/app-home-batched.test.ts

test/app-home-batched.test.ts now compares statement counts at two data sizes, and it still passes. The change is pushed, and tsc --noEmit is clean. I haven't seen the forge's check on this push.

Both tests changed:

• Same page, two sizes: each page is measured with 10 issues, 2 pulls and 1 run per repo, then again after growing to 200/40/5. The count may differ by at most 3 statements, which allows for the small shift in the fork page's own statements. A per-pull loop adds about 38, so it fails.
• Fork test: it checks that following appears in the server-timing header again, and it uses the same two-size comparison, so the fixed limit of 200 is gone.
• Check that it fails: I put a per-issue query inside the batch loop in src/core/pulls.ts. Both tests failed with counts of 56 and 119 over. I reverted that change.

A per-row cost the page already has: the first comparison failed on the unmodified page, which was 53 statements heavier at the large size. The page really does issue statements per row, so the "batched" claim is only partly true. Three statement shapes grow with the rows:

• the repo-visibility check, about one per visible pull and run;
• SELECT sealed, author_id FROM issue WHERE id = ?1, about one per run;
• the issue-by-id read, about one per run on the fork page.

I listed these in PER_ROW_TODAY in the test and left them out of the count. Without that the test would be red today. Every other statement must not grow with the rows. Fixing those three is a change to the app code, so it belongs in its own issue, and I didn't change src/. Once they are batched, delete the list.

I opened #6819 to track the three per-row probes, and the comment above PER_ROW_TODAY now cites it: "(#6819 batches them and removes this list)". The two tests in test/app-home-batched.test.ts still pass, and the change is pushed. I haven't seen the forge's check on this push.

#6819 is "The repo home batches its visibility, sealed and issue-by-id probes for pulls and runs". It names the three statements and says the list goes once they are batched.

Your second point stands: while the list exists, a new loop that reuses one of those three SQL shapes would go uncounted. The exclusion matches whole statement shapes, so I couldn't close that hole without changing src/. #6819 is what removes it.

The flake fix is unchanged: the test counts the SQL statements one GET prepares, at 10/2/1 and at 200/40/5 rows. The count may differ by at most 3.