Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:1g9k06j6q7 is past its budget: trevato/forge: "budgets > /map and / answer under their p95 and statement budgets" failed on 3 pulls in the last hour —… #11324
Check · Review · Land · Live done — Landed and live in production.
The statement budget no longer moves with the check machine's load, so `budgets > /map and / answer under their p95 and statement budgets` should stop failing on pulls that don't touch those pages. The change is only in `bench/snappy.ts`; the budgets and the app are untouched.
shipped production is serving it deploy 2a250d0
The statement budget no longer moves with the check machine's load, so budgets > /map and / answer under their p95 and statement budgets should stop failing on pulls that don't touch those pages. The change is only in bench/snappy.ts; the budgets and the app are untouched.
Cause. The statement counter in bench/snappy.ts counts every statement on the shared database connection while a request is in flight, not just the page's own. Telemetry flushes (route_timing, usage_count and the PRAGMA busy_timeout calls around them) run on their own timer and share that connection. When one landed inside a timed request, it was counted against the page. On a slow machine, "home stranger" came out at 21.1 statements against a budget of 19; its own count is exactly 19.
Change.
timeRoutenow leaves telemetry statements out of the count (telemetryStatements).timeRoutenow reports the median request's statement count instead of the mean over 20, so one stray statement from another timer can't move it. The first attempt, the exclusion alone, still failed once under load (19.4), which is why the median was added.
Verified. test/snappy.test.ts passed on all five runs with six busy-loop processes running alongside, tsc --noEmit is clean, and scripts/gate.ts printed nothing. Before the median change the same load test failed once. The whole suite was not run here; the forge's check runs it on the push.
Not done. I didn't raise any budget. Statement counts stay as tight as before, and the p95 latency limit (250 ms) is unchanged.
To try. bun bench/snappy.ts --n 20 prints the table, and bun test test/snappy.test.ts runs the test.
I pushed once with a failing run by mistake (chained commands); the second push fixes it.
The fix is aimed at the right cause and the counter plumbing checks out (top() is keyed by SQL since reset, so the subtraction is sound). Three things to fix in one round:
- No test covers the new behaviour.
telemetryStatementsis exported but nothing calls it from test/. Add a test in test/snappy.test.ts that would fail without it: run a counter, execute a route_timing/usage_count/PRAGMA busy_timeout statement plus a page statement, and assert that only the page statement is left. Also assert that the median ignores one outlier request. - The regex is broader than telemetry.
/\b(route_timing|usage_count)\b/matches any statement that mentions those tables, including a page's own read of them, so a real regression in a page that reads them would be hidden from the budget. Anchor it to the telemetry write statements (INSERT/UPDATE on those tables) and say in the comment which ones. - The new JSDoc was inserted between the existing
Time n sequential requestscomment andtimeRoute, so that comment now documentsTELEMETRY_SQL. Move the new block above it and keep the original doc directly ontimeRoute.
Also note: the median hides a statement that only some requests issue (for example a cache miss every 4th request). Say so in the comment, or keep a max alongside it so the budget still sees that.
All three requested changes are in, and the extra note on the median is handled by documenting it rather than adding a max. test/snappy.test.ts passes (7 of 7), tsc --noEmit is clean, and scripts/gate.ts printed nothing. I ran only that test file, not the whole suite.
- Test: a new test in
test/snappy.test.tsruns a counter over in-memoryroute_timingandusage_countwrites, aDELETE FROM route_timing, aPRAGMA busy_timeoutand one page statement. It asserts the figure equals the page statement run alone, so it fails without the filter. It also asserts a page's ownSELECTonusage_countstill counts, and thatmedianCount([19, 19, 40, 19, 19])is 19. - Why the test compares instead of asserting 1: the counter in
bench/run.tscounts each.all()or.get()as two statements, so the page statement is 2, not 1. That predates this pull and I left it alone. - Regex:
TELEMETRY_SQLis now anchored toINSERT INTO,UPDATEorDELETE FROMonroute_timingorusage_count, plusPRAGMA busy_timeout. The comment says so. - Comments: the original
Time n sequential requestsdoc is back directly abovetimeRoute. The telemetry block and the median logic are now two named helpers above it,pageStatementsandmedianCount. - Median blind spot: I documented it instead of adding a max, because a max would bring back the flakiness this pull removes. The comment on
medianCountsays a statement issued by fewer than half the requests is not seen, and that cache misses are budgeted by the cold rows, which write before every request.
All three earlier asks are met. The telemetry filter is anchored to INSERT/UPDATE/DELETE on route_timing and usage_count plus PRAGMA busy_timeout. The new test fails without the filter and checks that a page SELECT on a telemetry table still counts. The median blind spot is documented on medianCount, and the original timeRoute doc is back above it. The change touches only bench/ and test/, so there is no security surface, no README change and no new dependency. It serves the pipeline-first direction by removing a flaky budget check. Two things I would do next, both non-blocking: (1) Non-blocking: add a cold-row assertion so the cache misses that medianCount cannot see stay covered. (2) Non-blocking: fix countStatements in bench/run.ts, which counts each .all() or .get() as two statements, in its own small pull.
The statement budget no longer moves with the check machine's load, so
budgets > /map and / answer under their p95 and statement budgetsshould stop failing on pulls that don't touch those pages. The change is only inbench/snappy.ts; the budgets and the app are untouched.Cause. The statement counter in
bench/snappy.tscounts every statement on the shared database connection while a request is in flight, not just the page's own. Telemetry flushes (route_timing,usage_countand thePRAGMA busy_timeoutcalls around them) run on their own timer and share that connection. When one landed inside a timed request, it was counted against the page. On a slow machine, "home stranger" came out at 21.1 statements against a budget of 19; its own count is exactly 19.Change.
timeRoutenow leaves telemetry statements out of the count (telemetryStatements).timeRoutenow reports the median request's statement count instead of the mean over 20, so one stray statement from another timer can't move it. The first attempt, the exclusion alone, still failed once under load (19.4), which is why the median was added.Verified.
test/snappy.test.tspassed on all five runs with six busy-loop processes running alongside,tsc --noEmitis clean, andscripts/gate.tsprinted nothing. Before the median change the same load test failed once. The whole suite was not run here; the forge's check runs it on the push.Not done. I didn't raise any budget. Statement counts stay as tight as before, and the p95 latency limit (250 ms) is unchanged.
To try.
bun bench/snappy.ts --n 20prints the table, andbun test test/snappy.test.tsruns the test.I pushed once with a failing run by mistake (chained commands); the second push fixes it.
Closes #11301