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… #5699
Check · Review · Land · Live done — Landed and live in production.
This pull gives the "a gate that never answers is abandoned at the deadline" test the slow-machine timeout, which should stop it failing when the check machine is loaded. I haven't confirmed that was the cause of the failures. `test/merge-queue.test.ts` passes locally (16 pass), but the forge's loaded check machine is the real test.
shipped production is serving it deploy f9c1fcc
This pull gives the "a gate that never answers is abandoned at the deadline" test the slow-machine timeout, which should stop it failing when the check machine is loaded. I haven't confirmed that was the cause of the failures. test/merge-queue.test.ts passes locally (16 pass), but the forge's loaded check machine is the real test.
Cause (my best read): the test ran under bun's default 5 s timeout. It sets up a repo and a pull, waits out a 1.5 s gate deadline, then runs a second sweep that lands the pull. On a loaded machine the git setup alone can use up that 5 s, so the test timed out on the clock. The queue code was fine. The earlier fix (#5357) already covered the gate-start race with atGate, but not this timeout.
Fix: the test now uses the file's SLOW timeout (300 s), as the other setup-heavy tests in the file do. The 1.5 s deadline itself is unchanged, because the gate in this test never resolves.
Left out: I didn't change the other tests in the file that still use the default timeout, since only this one is named.
To try it, run bun test test/merge-queue.test.ts.
A one-line change: the abandoned-gate test gets the file existing SLOW timeout, like the other setup-heavy tests in merge-queue.test.ts. It touches only test code, so there is no security, terminal, or UI surface. The 1.5 s gate deadline is unchanged, so the test still checks what it did before. It is flaky-test stabilisation, which fits the stability priority. Caveat: the cause is a best read and has not been confirmed on a loaded machine. Next: (1) if it still flakes, give the other default-timeout tests in the file the same treatment; (2) look at whether the git setup these tests share can be made cheaper.
This pull gives the "a gate that never answers is abandoned at the deadline" test the slow-machine timeout, which should stop it failing when the check machine is loaded. I haven't confirmed that was the cause of the failures.
test/merge-queue.test.tspasses locally (16 pass), but the forge's loaded check machine is the real test.Cause (my best read): the test ran under bun's default 5 s timeout. It sets up a repo and a pull, waits out a 1.5 s gate deadline, then runs a second sweep that lands the pull. On a loaded machine the git setup alone can use up that 5 s, so the test timed out on the clock. The queue code was fine. The earlier fix (#5357) already covered the gate-start race with
atGate, but not this timeout.Fix: the test now uses the file's
SLOWtimeout (300 s), as the other setup-heavy tests in the file do. The 1.5 s deadline itself is unchanged, because the gate in this test never resolves.Left out: I didn't change the other tests in the file that still use the default timeout, since only this one is named.
To try it, run
bun test test/merge-queue.test.ts.Closes #5610