A workflow that runs on both push and pull_request runs the same check twice on one commit. The GitHub check deduper keeps the run with the newest timestamp: a finished run is dated by its completion, a live run by its start. When the pull_request run finishes first, it hides the push run that is still going. PR watch then wakes the agent with "All checks passed" while a check is still running, and the listing row and detail list show the check as passing.
In the GitHub rollup reader, a run that has not finished now ranks newest, so it outranks any finished run of the same check. A re-run still shows as the run happening now. Once every run has finished, the newest completion wins as before. A queued run with no start time, which used to drop out the same way, now holds too.
The change is in GitHub's reader only. Forgejo and Bitbucket share the deduper and are unchanged. No new GraphQL fields are requested.
Closes #17207. The triage comment confirms the cause on main. This is its option 1, applied where the rollup is deduped, so the watch gate, the reactor's in-flight flag, the listing row, and the detail list all read the same answer.
Not fixed: the triage comment's mirror case, where one event's run fails and the other's is still going. The live run now hides the failed run until it finishes, and once it passes the newest completion wins and the failure stays hidden. Telling independent runs apart needs more run identity from GitHub (event, run id, attempt) and handling for cancelled runs.
New test in gitHubPullRequestJson.test.ts with the issue's two runs (a finished pull_request run and an in-progress push run of Checks / check), in both listing orders, plus a queued run with no start time in both orders: the detail shows one pending check and the rollup reads pending. With the fix reverted it fails, showing the check as success.
In apps/server:
| 1 | vp test run src/pullRequest src/orchestration-v2/pullRequestWatch.test.ts |
25 files, 871 tests pass. Server typecheck, vp lint, and vp fmt --check on the two changed files pass.
After rebasing onto #17607, which moved the reader to packages/source-control-github: vp test run there passes 350 tests in 11 files, and the new test still fails without the fix. Package typecheck, vp lint, and vp fmt --check on the two changed files pass.
Not run against a live GitHub repository, and not run in a client by a person.
Model: Claude Opus 5.5, Claude Fable 5.1 (review), GPT-6-Astra (review). Harness: Claude Code, Codex.
Verdict: Approved at cea121e
Macroscope's review found this PR approvable — This is a focused GitHub check-rollup bug fix that changes only how duplicate completed and active runs are selected, with targeted coverage for ordering and queued-run cases. No product defaults, schemas, infrastructure, or static-analysis settings are changed.
You can add or adjust custom eligibility rules. Learn more.
Review in Change Stack →Review in Change Stack →
No actionable comments were generated in the recent review. 🎉
b9b3cf2b-7bbd-47c7-ae00-3db8cb2adf19Reviewing files that changed from the base of the PR and between cea121e31573bbe8a19fea7d0b0e0fa98cba9207 and dbcc96d47d1cf338b9cb3defe8ac7fb2442f09ac.
packages/source-control-github/src/server/gitHubPullRequestJson.test.tspackages/source-control-github/src/server/gitHubPullRequestJson.tsIncluded review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.
Pending check runs now take precedence over completed runs with the same check name and workflow during deduplication. Tests cover in-progress and queued runs in either listing order.
Duplicate check runs
| Layer / File(s) | Summary |
|---|---|
Pending run sorting packages/source-control-github/src/server/gitHubPullRequestJson.ts, packages/source-control-github/src/server/gitHubPullRequestJson.test.ts | Pending checks use a far-future timestamp for deduplication. Completed checks retain the existing completion-time-then-start-time selection. Tests verify that in-progress and queued runs remain pending when paired with completed successful runs, in either listing order. |
Priority: ➖ Normal
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix · Severity of issue fixed: Low
Suggested reviewers: juliusmarminge
Merge Risk: ⚪ Minimal · up to dbcc9
The change addresses the premature “checks passed” result for the stated scenario. No issue requiring a fix before merge is established.
| Check name | Status | Explanation |
|---|---|---|
| Linked Issues check | Passed | Issue #17207 requires PR watch to stay pending when a same-named check has another run in progress. The GitHub reader now ranks unfinished runs, including queued runs without a start time, above compl… |
| Out of Scope Changes check | Passed | The changes are limited to the GitHub reader and its regression test. They support issue #17207 through the shared deduplicated result used by PR watch and displayed checks. No unrelated Forgejo, Bitb… |
| Title check | Passed | The title is concise, specific, and accurately describes the primary fix: PR watch no longer reports success while another check run is still in progress. |
| Description check | Passed | The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the issue, implementation, scope limits, linked issue and approval, test coverage, validat… |
Comment @coderabbitai help to get the list of available commands.
Added 1 commit
