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

The require-review terminal test waits on the pull's loaded gate, not a 30 s screen poll, and passes 20 runs in a row beside the full suite #7590

shipped production is serving it opened this has it
opened this

Replaces #7586: main went red at 88e4bed on reviews, threads and the merge gate > require-review refuses the merge until the head is approved (test/tui-workflows.test.ts:314), twice not reproducible alone — so the fix is to take the timing out of the test, not to chase a run that passes.

Done when

  • [ ] The test no longer waits for screen text with a 30 s timeout (until(…, 30_000) at lines 335, 337, 351, 356, 357): it waits for the pull screen's gate state to have loaded (the session's own load promise or settle hook), then asserts the line once
  • [ ] If the pull screen can paint m before the require-review setting is read, that is fixed in the screen too (the merge key is refused with the gate's words, never merges, while the setting is loading), with a test that fails without the fix
  • [ ] for i in $(seq 20); do bun test test/tui-workflows.test.ts || break; done is green 20 of 20 while bun test runs in parallel in another shell; the pull says so with the count
  • [ ] No other test in the file changes behaviour

Files: test/tui-workflows.test.ts, src/tui/screens/pull.ts (only if the gate can be raced)

Risks. Hiding a real race behind a longer wait: if the screen can act before its gate loads, the screen is the bug.

Suggested brief: scout (a person assigns).

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs