fix(scheduler): hold pre-review branch updates while current-head checks are in flight

[seonghobae]

Fixes the self-cancelling loop measured in #1935.

What changes

• scripts/ci/pr_review_merge_scheduler_core.py: new has_in_flight_check_runs(pr) (one expression over the existing latest_check_runs / running_check_state), and one guard in the pre-review branch of inspect_pr: when the PR is behind, unreviewed, and any newest current-head check run is still QUEUED/IN_PROGRESS/PENDING/…, the decision is wait instead of update_branch. The reason string keeps the existing prefix so log consumers that match on branch is outdated before review dispatch still match.
• No age cap on the hold, deliberately: a cap would restart the loop this change removes. A check that never finishes keeps the head where it is; the update resumes on the next heartbeat after every newest check run is terminal.
• tests/test_pr_review_merge_scheduler.py: contract test with the positive case (queued + in-progress + one success → wait, both reason fragments), the negative control (all terminal → update_branch, prefix unchanged, hold fragment absent), and the empty-rollup case.
• CLAUDE.md: the governance paragraph said the scheduler updates a branch only after approval; it now describes both update paths (post-approval, and pre-review when no check is in flight).
• CHANGELOG.md entry.

Why this is the smallest root-cause change

Under the current queue a scheduler run executes 2h+ after it was created, picks one behind PR from its scan (its own PR or another one — a codex/originweave-mv3-owner run updated #1857), and merges main into that head before dispatching any review (core.py:4774-4792, UPDATE_BRANCHES true for pull_request_target at pr-review-merge-scheduler.yml:139). With main moving every ~28 minutes almost every completing run finds a behind PR, so the scheduler's completion rate becomes the PR cancellation rate. Each push cancels every queued check on the old head — 22/28 on #1926, 21/30 on #1484 with 8 successes orphaned — and requeues the PR at the back. Reconstructed at merged_at, 76 of the 77 PRs merged here since 2026-09-04 had 0/12 required contexts satisfied.

The guard removes the pre-review self-cancellation without touching the post-approval update, which main's required_status_checks.strict=true still requires. Alternatives considered: dropping pull_request_target from UPDATE_BRANCHES (only makes the schedule/push sweeps do the same thing less often); an age cap on the hold (reintroduces the loop); dispatching the review on the behind head (wasted under strict=true, since the post-approval update changes the SHA and invalidates a same-head approval).

Not claimed

• Does not make PRs converge on its own while main moves faster than a head's checks can complete — it stops the scheduler from being the thing that resets them, and lets each head accumulate evidence. Post-approval updates under strict=true are a separate, bounded cost.
• Does not touch opencode-review-dispatch rejects the current dispatcher identity: allowlist says github-actions[bot], sender is opencode-agent[bot] #1929/vars.OPENCODE_REPOSITORY_DISPATCH_ACTOR is stale: every dispatch is rejected since 2026-08-31 #1927 (dispatch actor variable), Queue delay invalidates its own dispatches: base_sha equality fails 12 of 16 validate-pr-metadata runs #1931 (dispatch-side base_sha drift), or codeql-scan-dispatch.yml has never run: env: cannot hold the client_payload matrix array (0 success / 136 failures since #1776) #1925 (CodeQL dispatch).
• Only CheckRun nodes are considered (latest_check_runs filters on __typename == "CheckRun"); a legacy commit StatusContext that is still pending does not hold the update. All 12 required contexts on this repository's main are Actions check runs, so nothing here depends on it — a docstring line for the helper is a follow-up, kept out of this head so the merge procedure does not restart.
• Jobs behind needs: are created only when their upstream completes, so for a few seconds between an upstream job finishing and its dependants appearing every existing check run is terminal and the hold does not apply. With one scheduler run per hour per PR that window is negligible, and landing in it reproduces today's behaviour rather than anything worse.

Verification

Full gate on this head with GITHUB_ACTIONS=true (the env gate at core.py:4172 is what makes these tests run the same code CI runs): 2893 passed / 1 skipped / 21 subtests, coverage report --fail-under=100 → 100%, interrogate → 100%; negative control: the new test fails (1 failed) with origin/main's pr_review_merge_scheduler_core.py swapped in.

Chicken-and-egg note for the merger: this PR's own required contexts are produced by the queue this change unblocks; its head cannot self-validate. Same category as #1932 and #1926.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

Next included review available in 7 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 3a1c8211-33df-48b5-a9db-d8eea8561e27

📥 Commits

Reviewing files that changed from the base of the PR and between 3f88e13 and d05856f.

📒 Files selected for processing (4)

• CHANGELOG.md
• CLAUDE.md
• scripts/ci/pr_review_merge_scheduler_core.py
• tests/test_pr_review_merge_scheduler.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}