Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:10xbuym6wf is past its budget: trevato/forge: "build yield reads event through its index, never a scan of event or a run per run" failed on 3 pulls in… #12130

I fixed the failing test in test/stall-scans.test.ts that the sentinel flagged (#12096): "build yield reads event through its index, never a scan of event or a run per run". The test was wrong, not the code.

Cause: the test required the plan to name run_kind_finished for the run side of BUILD_YIELD_SQL. Commit 2bc9f347f added run_finished_cov, which starts with the same columns (kind, finished_at, …) and also covers the other columns the query reads. SQLite now prefers it, so the plan reads SEARCH x USING INDEX run_finished_cov (kind=? AND finished_at>? AND finished_at<?). The query is just as fast as before; only the index name changed. It failed the same way in this clone, so it was not the check machine's load, disk or clock. Which of the two near-identical indexes SQLite picks is left to its own internal ranking, which may be why main's check passed while the pulls failed.

Fix: the assertion now checks the shape of the search, not the index name. run must be a SEARCH on some index with a kind=? match and a finished_at range. The test still fails if run is scanned, if event is scanned, or if run is matched on kind alone. The query and the other five tests are unchanged.

I chose not to add INDEXED BY run_kind_finished to the query. It would hold the plan steady, but it would stop SQLite using the better covering index.

Checks: bun test test/stall-scans.test.ts passes (6 of 6), and bun scripts/gate.ts and bun x tsc --noEmit are clean. To try it, run bun test test/stall-scans.test.ts.

🤖 Generated with Claude Code

Closes #12096

I fixed the failing test in test/stall-scans.test.ts that the sentinel flagged (#12096): "build yield reads event through its index, never a scan of event or a run per run". The test was wrong, not the code.

Cause: the test required the plan to name run_kind_finished for the run side of BUILD_YIELD_SQL. Commit 2bc9f347f added run_finished_cov, which starts with the same columns (kind, finished_at, …) and also covers the other columns the query reads. SQLite now prefers it, so the plan reads SEARCH x USING INDEX run_finished_cov (kind=? AND finished_at>? AND finished_at<?). The query is just as fast as before; only the index name changed. It failed the same way in this clone, so it was not the check machine's load, disk or clock. Which of the two near-identical indexes SQLite picks is left to its own internal ranking, which may be why main's check passed while the pulls failed.

Fix: the assertion now checks the shape of the search, not the index name. run must be a SEARCH on some index with a kind=? match and a finished_at range. The test still fails if run is scanned, if event is scanned, or if run is matched on kind alone. The query and the other five tests are unchanged.

I chose not to add INDEXED BY run_kind_finished to the query. It would hold the plan steady, but it would stop SQLite using the better covering index.

Checks: bun test test/stall-scans.test.ts passes (6 of 6), and bun scripts/gate.ts and bun x tsc --noEmit are clean. To try it, run bun test test/stall-scans.test.ts.

🤖 Generated with Claude Code