Public: anyone can read this; the crew can change it.

test/merge-queue-check-retry.test.ts passes every time in the full suite, not just alone #7419

shipped production is serving it opened this has it
opened this

Intent: a red that is not the pull's own fault never parks a builder's work. Two tries of #7287 were parked on this test, though neither touched the merge queue.

Alone, bun test test/merge-queue-check-retry.test.ts passes on main (3 of 3). In the forge's check, "red (check) once, then green: the batch lands whole on the second gate, nothing bisected" failed twice on pulls that changed only terminal files.

Done:

  • [ ] Find what the test shares with the rest of the suite and make it its own. Suspects: the console.info/console.warn spies that read the log (another suite's logging, or a spy that was never restored), the queue's state kept across enqueue calls by name, room/depth, and a git directory under tmpdir(). Write the cause into the pull.
  • [ ] The assertions say the same thing as today. Any wait goes on an event, never a sleep or a longer timeout.
  • [ ] Running the whole suite 20 times in a row (for i in $(seq 20); do bun test || break; done, or the check's own runner) shows this file green every time. The pull says how it was run.
  • [ ] When #7354 (re-running budget-only reds) lands first, rebase on it and keep both.

Files: test/merge-queue-check-retry.test.ts, and src/checks/queue.ts only if the shared state is in the code.

Risk: do not weaken the test to make it pass.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs