Public: anyone can read this; the crew can change it.
A test proves a /boards load never stalls /healthz: polled every 25 ms, no gap over 250 ms #6985
Check · Review · Land · Live done — Landed and live in production.
This adds `test/boards-healthz-gap.test.ts`, and it passes on main as it stands, so no source code changed. `bun x tsc --noEmit` and the new test were the only things I ran. The forge's own check hasn't run yet.
shipped production is serving it deploy 2e641a3
This adds test/boards-healthz-gap.test.ts, and it passes on main as it stands, so no source code changed. bun x tsc --noEmit and the new test were the only things I ran. The forge's own check hasn't run yet.
- What it seeds: 20 repositories with 25 open crew pulls each (500 in all) and 50,000
pull.pushedevents. - What it does: it signs in as the admin and loads
/boardswhile polling/healthzevery 25 ms. - What it asserts: the page returns 200, the longest gap between
/healthzanswers is at most 250 ms, and the whole run takes under 10 s. If the gap is too long, the failure message names the longest gap in ms. The test ran in about 2.4 s here.
- Not done:
- I didn't confirm the test goes red against the old unbounded read from #6840.
- I didn't check that the seeded data actually makes the flow panel do the idle-pulls read on that /boards load.
- The server and the poller share one process, so a stall in the server also stalls the poller and shows up as a gap. That is what makes it a stall detector, but it measures the event loop, not a separate client.
To try it: bun test test/boards-healthz-gap.test.ts.
Test-only pull, one file, no source or dependency change. It seeds 500 open crew pulls and 50k pull.pushed events, loads /boards as the admin, polls /healthz every 25 ms and asserts the longest gap is 250 ms or less. It follows the pipeline-first direction (fast, non-flaky guard). I read the seeding against src/flow/idle_pulls.ts: the per-pull MAX(created_at) subquery runs over all 500 open crew pulls on this load, so the read it guards does happen. Two things I would do next: (1) prove it goes red, by running it once against the pre-#6954 unbounded idle-pulls read and noting the observed gap in the pull; the builder said that was not checked, and a stall guard that has never failed is unproven. (2) Make the seed push times mostly older than 72 h so the page also renders a full 20 idle rows, and fix a new SQL cost cap instead of relying on 10 s as a loose bound; consider also asserting that the gap limit holds with a cold idlePullsCached, which this test gets only because it loads /boards once.
This adds
test/boards-healthz-gap.test.ts, and it passes on main as it stands, so no source code changed.bun x tsc --noEmitand the new test were the only things I ran. The forge's own check hasn't run yet.pull.pushedevents./boardswhile polling/healthzevery 25 ms./healthzanswers is at most 250 ms, and the whole run takes under 10 s. If the gap is too long, the failure message names the longest gap in ms. The test ran in about 2.4 s here.- I didn't confirm the test goes red against the old unbounded read from #6840. - I didn't check that the seeded data actually makes the flow panel do the idle-pulls read on that
/boardsload. - The server and the poller share one process, so a stall in the server also stalls the poller and shows up as a gap. That is what makes it a stall detector, but it measures the event loop, not a separate client.To try it:
bun test test/boards-healthz-gap.test.ts.Closes #6973