Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:30jm3u45lg is past its budget: trevato/forge: "the merge queue > ten green pulls: a candidate carries eight, the next the other two, and the log says … #5139
Check · Review · Land · Live done — Landed and live in production.
I pinned the log floor in the "ten green pulls" test, but I never reproduced the failure, so it is a best guess at the cause. The 16 merge-queue tests pass, and the type check couldn't run here because the `bun` type definitions weren't found.
shipped production is serving it deploy 4345bb2
I pinned the log floor in the "ten green pulls" test, but I never reproduced the failure, so it is a best guess at the cause. The 16 merge-queue tests pass, and the type check couldn't run here because the bun type definitions weren't found.
What changed. The test reads the queue's own [queue] gating … and gated … lines from console.info. Those lines are only emitted while the log floor is info, and the floor is process-wide. Other tests lower or raise it (helpers.test.ts sets it to warn), so a leftover floor would make this test see no lines and fail, however correct the queue was. The test, and the "after a red batch" test, which reads the same lines, now set the floor to info around the sweep and restore it afterwards. The change is in test/merge-queue.test.ts.
What I checked. The queue logic itself is deterministic here. I ran the whole file three times with three busy-loop processes competing for CPU, and it passed every time. An earlier fix on this branch (#4986) already raised the test's timeout to 60 s, and the failure still came back. That is why I suspect something other than load.
What I left out. I didn't touch the other test files that change the floor.
To try it. Run bun test test/merge-queue.test.ts. The sentinel cause should clear once main has a green check.
Test-only change. Both tests that read the queue's [queue] log lines now pin the process-wide log floor to info and restore it in finally. This is the same logLevel/setLogLevel pattern first-admin.test.ts and crew-reserve.test.ts already use. helpers.test.ts sets the floor to warn, so a leaked floor is a plausible cause of the sentinel failure. No production code, UI or dependency changes, so nothing to check in the preview. Two things to do next: (1) fold the repeated floor/restore into one helper, or use test/helpers/globals.ts, which already does this per file; (2) scout did not reproduce the failure, so watch the next few main checks to confirm the cause, and if it recurs look for state leaking between files rather than load.
The merge queue's "ten green pulls" test (#3430) failed because of the process-wide log floor. The fix is already on this branch and pushed, as 3986c2c7, but it hasn't reached main yet, so Sentinel's new failures at 06:45 and 07:20 are most likely main still running without it.
Cause: the test reads the queue's [queue] gating … and [queue] gated … lines through console.info. The log level is shared across the whole process. If an earlier test left it above info, those lines were never written and the assertions failed. How often that happened depended on which tests ran before it.
Fix: that test (and the #4053 rebatch test, which also reads these lines) now saves the log level, sets it to info while it listens, and restores it afterwards. The change is only in test/merge-queue.test.ts.
Verified: I ran bun test test/merge-queue.test.ts three times on this branch. All 16 tests passed each time, 151 expectations each. I did not run the full suite, since the forge's check does that on push.
Left out: I did not look for other tests that depend on the log level, and I did not change the logger. Once this lands, the failing check should clear on its own.
I pinned the log floor in the "ten green pulls" test, but I never reproduced the failure, so it is a best guess at the cause. The 16 merge-queue tests pass, and the type check couldn't run here because the
buntype definitions weren't found.What changed. The test reads the queue's own
[queue] gating …andgated …lines fromconsole.info. Those lines are only emitted while the log floor isinfo, and the floor is process-wide. Other tests lower or raise it (helpers.test.tssets it towarn), so a leftover floor would make this test see no lines and fail, however correct the queue was. The test, and the "after a red batch" test, which reads the same lines, now set the floor toinfoaround the sweep and restore it afterwards. The change is intest/merge-queue.test.ts.What I checked. The queue logic itself is deterministic here. I ran the whole file three times with three busy-loop processes competing for CPU, and it passed every time. An earlier fix on this branch (#4986) already raised the test's timeout to 60 s, and the failure still came back. That is why I suspect something other than load.
What I left out. I didn't touch the other test files that change the floor.
To try it. Run
bun test test/merge-queue.test.ts. The sentinel cause should clear once main has a green check.Closes #5129