Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2tcvuk57nu is past its budget: trevato/forge: "the merge queue > a gate that never answers is abandoned at the deadline, and the next sweep lands (#34… #5138
Check · Review · Land · Live done — Landed and live in production.
This fixes the flaky merge-queue test "a gate that never answers is abandoned at the deadline, and the next sweep lands (#3430)". I haven't confirmed it fixes the failures on the forge. `test/merge-queue.test.ts` passes locally (16 tests, ~9 s), and I did not run the type check or the whole check.
shipped production is serving it deploy f8d173e
Test-only deflake of the #3430 abandoned-gate test. The gate deadline goes from 300 ms to 1500 ms. The wait for the gate to start goes from 1 s to 30 s of polling (6000 × 5 ms). The assertions are unchanged and the deadline is still short, so the test still fails if the abandon-at-deadline behaviour is removed. No product code, dependency or security surface changes. Next: (1) have the test await the gate signal with a deadline-bounded helper instead of a poll loop; (2) check whether other timing-based queue tests share the same slack on a loaded machine.
This pull makes the "gate that never answers is abandoned at the deadline" test in test/merge-queue.test.ts independent of how loaded the check machine is. It is the fix for #5127. The one commit, a99f61f2, was already on this branch, and I added nothing new this turn.
- Cause: The test gave the gate a 300 ms deadline. It also waited at most about 1 s for the gate to start, because building the candidate is git work first. On a loaded check machine the deadline could pass, or the wait could give up, before the test looked at the queue. That is why it failed on three unrelated pulls.
- Fix: The deadline is now 1500 ms, and the wait for the gate to start can run up to 30 s. Both changes are in the test only. The queue code is untouched, since the behaviour under test was correct.
- Verification: I ran
test/merge-queue.test.tsthree times locally. All 16 tests passed each time, in about 10 s. - Not done: The test still uses a real deadline rather than a fake clock. A fake clock would need a clock seam in the queue, which is more than this fix warrants. The test will still pass only if the gate starts within 1.5 s of the sweep, which is far more headroom than before.
- Closing the issue: The sentinel's degraded entry should clear once this lands on
mainand the next check goes green. Pulls that were red on this test alone then proceed.
This fixes the flaky merge-queue test "a gate that never answers is abandoned at the deadline, and the next sweep lands (#3430)". I haven't confirmed it fixes the failures on the forge.
test/merge-queue.test.tspasses locally (16 tests, ~9 s), and I did not run the type check or the whole check.Cause. The test gave the gate a 300 ms deadline. It then waited for the gate to start and asserted the queue read "gating 1 pull". On a loaded check machine the deadline could pass before that assertion ran, so the queue already read "idle" and the test failed. It's a timing race in the test, not a bug in
src/checks/queue.ts.Change. The deadline is now 1500 ms. That leaves plenty of room for the "gating" check, and the test still ends at the deadline as before. The wait for the gate to start is now bounded at about 30 s, up from 1 s, so slow git setup on a busy machine no longer runs out the wait.
Left out. I didn't make the deadline injectable per call or add fake timers. The test already uses the queue's real timer, and it only waits about 1.5 s.
To try it:
bun test test/merge-queue.test.ts.Closes #5127