Repository navigation
pr status counts cancelled runs as failures despite newer successful run #12895
Description
Describe the bug
When a GitHub Actions workflow uses concurrency with cancel-in-progress: true, cancelled runs are counted as failures in gh pr status and gh pr view --json statusCheckRollup, even when a newer run for the same check name has succeeded. The GitHub web UI handles this correctly and shows "All checks passed". Also gh pr checks correctly shows the check as passing.
Affected version
gh version 2.87.3 (2026-02-23)
Steps to reproduce the behavior
- Have a workflow with
concurrency: { cancel-in-progress: true }triggered bylabeled/unlabeledevents - Labels are changed in quick succession, causing some runs to be cancelled
- Run
gh pr status. Expected output:
#105183 drivers: stepper: fix doxygen grouping [user:branch]
✓ Checks passing
- Actual output:
#105183 drivers: stepper: fix doxygen grouping [user:branch]
× 1/47 checks failing - Review required
- Yet
gh pr checkscorrectly shows the check as passing:
$ gh pr checks 105183
Prevent Merging pass 40s https://github.com/zephyrproject-rtos/zephyr/actions/runs/...
- The check rollup includes both the cancelled and successful runs:
$ gh pr view 105183 --json statusCheckRollup | jq '.statusCheckRollup[] | select(.name == "Prevent Merging") | {name, conclusion}'
{ "name": "Prevent Merging", "conclusion": "CANCELLED" }
{ "name": "Prevent Merging", "conclusion": "SUCCESS" }
Expected vs actual behavior
Expected: gh pr status should show checks as passing when the latest run for each check name has succeeded, consistent with the web UI ("All checks passed, 2 skipped 32 successful") and gh pr checks.
Actual: gh pr status counts the stale cancelled run as a failure, showing × 1/47 checks failing.
Logs
See zephyrproject-rtos/zephyr#105175 for discussion and additional affected PRs (#105182, #105183).
Activity
fix(pr status): don't count cancelled checks as failures
BagToad commentedon Mar 13, 2026
I think this misalignment in behavior between the two commands makes sense to fix. Thanks for the report @npitre
blackwell-systems commentedon Apr 27, 2026
I'd like to work on this. The root cause is that
ChecksStatus()inapi/queries_pr.goiteratescontexts.Nodeswithout deduplication, so stale cancelled runs are counted alongside the newer successful run for the same check. The fix would apply the same deduplication pattern already used inpkg/cmd/pr/checks/aggregate.go(sort byStartedAtdescending, keep only the most recent entry per check name).Could this be labelled
help wantedso I can submit a PR?ci: skip red PRs + use App token so update-branch retriggers CI
[ci] wait_for: github.ci via gh pr checks; drop github.pr_closed
npitre commentedon Aug 3, 2026
Still reproduces on current
main. Concrete case today, zephyrproject-rtos/zephyr#115239:Nothing is failing. "Prevent Merging" ran five times on the same head as different events fired, concurrency cancelled three older runs, and the newest succeeded.
pr checkscollapses those five to one row,pr statuscounts all five, hence 30 versus 23.Five months on, four attempts at this have come and gone:
pr status#12906 (@BagToad) was approved by @williammartin and then closed by its author on 2026-05-04 with no comment.help wantedlabel", so neither was reviewed on its merits.Could a maintainer say what would be acceptable here? Either the approach is wrong, in which case saying so once saves the next four attempts, or it is fine and the blocker is procedural, in which case adding
help wantedto this issue would let a community fix through instead of the bot closing it in four days.One technical note that may be the reason #12906 was withdrawn, and which invalidates the two community attempts regardless of the label. For github.com,
pr statusnever runs the code they modified:pkg/cmd/pr/status/status.gofeedsCheckRunAndStatusContextCountsintopkg/cmd/pr/status/http.go, which selects thestatusCheckRollupWithCountByStatefragment, soChecksStatus()takes the fast path inapi/queries_pr.gowhereTotal = CheckRunCount + StatusContextCountand the buckets come from pre-aggregatedcheckRunCountsByState. #13563 and #13658 added dedup to the node path, whichpr viewuses andpr statusdoes not, so neither would have changed the3/30above.That fast path carries no per-check identity, so dedup is impossible there. The real choice looks like dropping the countsByState fast path for
pr statusand paying for the paginated node query, or approximating as #12906 did by subtracting cancelled from the total, which also hides a genuinely cancelled required check, and such a check does block merging in the web UI.My own view is that dedup is the right target rather than reclassifying
CANCELLED: once the newest run per check wins, a stale concurrency victim disappears on its own while a real cancelled check still reads as not passing, matching the web UI. The two commands disagreeing about how many checks a PR has is the defect. Whetherpr statusfoldsskippingintopassingis presentation and fine either way.