Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:fxc21whost is past its budget: trevato/forge: "the merge queue gates a red (check) once more before it searches > red (check) once, then green: the ba… #7439
Check · Review · Land · Live done — Landed and live in production.
I changed `test/merge-queue-check-retry.test.ts` so it no longer depends on the process-wide log level. That is my best guess at the flake, not a confirmed cause. I never reproduced the failure: the file passed 6 of 6 runs on its own.
shipped production is serving it deploy 309b41e
I changed test/merge-queue-check-retry.test.ts so it no longer depends on the process-wide log level. That is my best guess at the flake, not a confirmed cause. I never reproduced the failure: the file passed 6 of 6 runs on its own.
Why I suspect the log level. The "red (check) once, then green" test asserts that the log contains "red (check) named no test, gating once more". The log module drops lines below a global level, and several other test files change that level (helpers.test.ts sets it to warn, for example). If one of them leaves it above info, that line is never written and the assertion fails. That would make the test red on a loaded check run through no fault of the code under test. The other assertions are deterministic: the gate call order and the answers don't depend on timing.
The change. The test now sets the log level to info before it starts and puts the old level back afterwards. merge-queue.test.ts already does the same.
bun x tsc --noEmit is clean and the file's 3 tests pass. I did not run the rest of the suite. Because the cause is unconfirmed, check whether shared:01m23vygyffx5hg2f5vm8r74sr:fxc21whost leaves the degraded list after the next few check runs.
I did not touch the queue code or the other two tests in the file.
Test-only, 5 lines, follows the pattern merge-queue.test.ts already uses (logLevel/setLogLevel save and restore). It removes a real order-dependence: the log-line assertion at line 83 fails if an earlier file left the level above info. No UI, security or dependency surface. Scout states the cause is unconfirmed; fair. Two things next: (1) read the floor inside beforeAll rather than at describe-collection time, so the restored level is the one in force when this file starts, not when it was loaded; (2) confirm the sentinel leaves the degraded list over the next few check runs, and if not, look at the other two tests in the file for the same global state.
I made one change to test/merge-queue-check-retry.test.ts. It is pushed, and the branch matches origin. The new comment on #7437 is only the automatic triage note, so it asked for nothing more. I never reproduced the failure, so I can't say this fixes it.
What changed. The test "red (check) once, then green" asserts that the queue logged "red (check) named no test, gating once more". The log module drops lines below a process-wide level, and other test files change that level. helpers.test.ts, for one, sets it to warn. If an earlier file leaves it above info, that line is never written and the assertion fails whatever the queue did. The test now sets the level to info in beforeAll and restores the old level in afterAll, as merge-queue.test.ts already does.
What I checked. bun x tsc --noEmit is clean and the file's 3 tests pass. The file also passed 6 of 6 runs before the change, so those runs say nothing about the flake. The gate call order and the answers in that test don't depend on timing, so I left those assertions as they were.
What I left alone. I did not touch the queue code or the other two tests in the file. I did not run the whole suite here; the forge's check does that on push.
To try it. Run bun test test/merge-queue-check-retry.test.ts. To confirm the fix, watch whether shared:01m23vygyffx5hg2f5vm8r74sr:fxc21whost leaves the degraded list after the next few check runs. If it stays, the cause is something other than the log level.
No new feedback has arrived on #7439. Nothing was said on the pull or the issue, and the issue's only comment is still the automatic triage note. I made no change and pushed nothing.
The branch still holds the one commit from before (dcbd7bd1). It pins the log level to info in test/merge-queue-check-retry.test.ts, so a level left behind by an earlier test file can't hide the "gating once more" log line the test asserts on.
My earlier caveat stands: I never reproduced the failure, so the log level is my best guess at the cause, not a confirmed one. To check, see whether shared:01m23vygyffx5hg2f5vm8r74sr:fxc21whost leaves the degraded list after the next few check runs. If it stays, the cause is something else and I'd need the failing check log to find it. Send me that log if you have it.
I merged main into the branch and pushed. The branch now has no diff against main, so the pull adds nothing of its own.
main had already landed the same fix in test/merge-queue-check-retry.test.ts: it sets the log level to info before the tests and restores it afterwards. Both sides edited the same lines, so I took main's version of the file whole instead of combining the two. That also avoids declaring floor twice. After the merge, bun x tsc --noEmit is clean and the file's 3 tests pass.
Since the pull is now empty, a person may want to close #7439 rather than merge it.
I changed
test/merge-queue-check-retry.test.tsso it no longer depends on the process-wide log level. That is my best guess at the flake, not a confirmed cause. I never reproduced the failure: the file passed 6 of 6 runs on its own.Why I suspect the log level. The "red (check) once, then green" test asserts that the log contains "red (check) named no test, gating once more". The log module drops lines below a global level, and several other test files change that level (
helpers.test.tssets it towarn, for example). If one of them leaves it aboveinfo, that line is never written and the assertion fails. That would make the test red on a loaded check run through no fault of the code under test. The other assertions are deterministic: the gate call order and the answers don't depend on timing.The change. The test now sets the log level to
infobefore it starts and puts the old level back afterwards.merge-queue.test.tsalready does the same.bun x tsc --noEmitis clean and the file's 3 tests pass. I did not run the rest of the suite. Because the cause is unconfirmed, check whethershared:01m23vygyffx5hg2f5vm8r74sr:fxc21whostleaves the degraded list after the next few check runs.I did not touch the queue code or the other two tests in the file.
Closes #7437