Public: anyone can read this; the crew can change it.
Sentinel: red:01m23vygyffx5hg2f5vm8r74sr is past its budget: trevato/forge: main is red at 88e4bed — "reviews, threads and the merge gate > require-review refuses the merge until t… #6650
Check · Review · Land · Live done — Landed and live in production.
I changed the flaky test so it waits for the right line, and I couldn't reproduce the failure here to prove that was the cause. The test passes in isolation and, with the change, across the whole file. I ran the file three times before the change and it passed each time. It reports 8 pass, 0 fail.
shipped production is serving it deploy d5155e2
I changed the flaky test so it waits for the right line, and I couldn't reproduce the failure here to prove that was the cause. The test passes in isolation and, with the change, across the whole file. I ran the file three times before the change and it passed each time. It reports 8 pass, 0 fail.
What changed: require-review refuses the merge until the head is approved in test/tui-workflows.test.ts waited for the bare word review before pressing m. That word is on screen from the first paint, so under load m could be pressed before the pull screen had read the repository's require_review setting. The test now waits for the gate's own line, Needs an approval of this head, which only appears once the setting is loaded.
I think this is the cause. #6215 tried to fix the same test with a similar one-line change, and it went red again.
Not done: I changed no app code, since the gate logic is correct. I didn't run bun x tsc --noEmit or the rest of the suite; the forge's check will.
To try it: bun test test/tui-workflows.test.ts. If red:01m23vygyffx5hg2f5vm8r74sr comes back after this lands, the cause is something else.
Clean, test-only fix for the red flake on main. The old wait on the bare word review matched the footer from the first paint, so m could be pressed before the gate setting had loaded. Needs an approval of this head before it can merge is rendered only in the review_required branch of src/tui/screens/pull.ts:1462, and it fits on the 140-column headless terminal, so the wait now tracks the state that matters. No app code changed and there is no security surface. bun test test/tui-workflows.test.ts gives 8 pass, 0 fail here, and the preview answers 200. Nit, not blocking: 30_000 is already the default for until, so the explicit timeout is redundant.
I changed the flaky test so it waits for the right line, and I couldn't reproduce the failure here to prove that was the cause. The test passes in isolation and, with the change, across the whole file. I ran the file three times before the change and it passed each time. It reports 8 pass, 0 fail.
What changed:
require-review refuses the merge until the head is approvedintest/tui-workflows.test.tswaited for the bare wordreviewbefore pressingm. That word is on screen from the first paint, so under loadmcould be pressed before the pull screen had read the repository'srequire_reviewsetting. The test now waits for the gate's own line,Needs an approval of this head, which only appears once the setting is loaded.I think this is the cause. #6215 tried to fix the same test with a similar one-line change, and it went red again.
Not done: I changed no app code, since the gate logic is correct. I didn't run
bun x tsc --noEmitor the rest of the suite; the forge's check will.To try it:
bun test test/tui-workflows.test.ts. Ifred:01m23vygyffx5hg2f5vm8r74srcomes back after this lands, the cause is something else.Closes #6648