Public: anyone can read this; the crew can change it.
checks.concurrency: no test fails without gate.resize in the checks scheduler #10243
Check · Review · Land · Live done — Landed and live in production.
A test in `test/capacity.test.ts` now fails if `gate.resize(limit)` is removed from `schedule()`.
shipped production is serving it deploy 47e6991
Clean, one-line test change. checks.lane is the scheduler Gate (service.ts:1738), booted at 3; schedule() resizes it only via line 622, and the admission loop reads limit directly, so without the resize the lane stays at limit 3 and the new assertion fails. No security, dependency or docs surface touched.
Left #10231 open: 1 unticked item remain (Or, if the resize turns out to be redundant with the other admission reads, it is removed with a note saying which read enforces the limit.).
A test in
test/capacity.test.tsnow fails ifgate.resize(limit)is removed fromschedule().The "lowered to one" test already boots the checks service at three. I added one assertion to it: once the three checks have finished,
checks.lane.limitmust be 1. Withgate.resize(limit)replaced byvoid limit, that assertion fails. With the line restored, the test passes andtsc --noEmitis clean. I ran only that one test, not the rest oftest/capacity.test.ts.The resize is not redundant:
spareSlotsand the other admission reads keep the checks to one at a time on their own, but the gate itself keeps its boot limit unless the resize runs. I chose to test it, sosrc/checks/service.tsis unchanged.I tested only the lowering case. I did not add a test for raising above the boot count, because that needs a second scheduler tick and the issue asks for only one of the two.
To try it:
bun test test/capacity.test.ts -t "lowered to one".🤖 Generated with Claude Code
Closes #10231