Required check PASS but merge BLOCKED with same-head cancelled and successful Actions suites

[DankerMu]

Observed behavior

In a public repository with one required context (all-checks-passed), simultaneous pull_request events on the same head can leave gh pr checks --required reporting PASS while GraphQL mergeStateStatus remains BLOCKED. In one occurrence the normal gh pr merge was rejected by branch policy. Another same-head overlap became CLEAN without intervention. We are asking which duplicate-check-suite selection rule branch protection applies; we are not claiming a confirmed GitHub internal root cause.

Repository issue with preserved baseline and public evidence: DankerMu/SHUD-Harness#479 . Workflow: https://github.com/DankerMu/SHUD-Harness/blob/2441567d918edea473e32039547eb73068def1bd/.github/workflows/ci.yml .

The workflow subscribes to opened/synchronize/reopened/labeled/unlabeled, uses one concurrency group per workflow/ref with cancel-in-progress=true, and an always() aggregator requiring seven jobs. An aggregate correctly fails if any dependency fails, is cancelled, or is skipped. We do not want to weaken this gate.

Public observations

PR/head	Cancelled suite / run	Successful suite / run	Observed result
477, 574dda4026319dc2f3fb29a6cc4a7fd0360825a4	111046662989 / 40964477587	111046662985 / 40964477590 attempts1/2	required PASS, BLOCKED, ordinary merge rejected
496, c079cc16e80e0dd0bd69cbb7a76ccea8d9525a0c	111712601577 / 41212692050 attempt1	111712601492 / 41212692010	required PASS, BLOCKED; rerun cancelled suite all jobs at same head -> CLEAN
506, 2441567d918edea473e32039547eb73068def1bd	111782628915 / 41239596369	111782628924 / 41239596372	required PASS, CLEAN without intervention; ordinary merge succeeded

PR477 cancelled aggregate123765322410 FAILURE persisted alongside green aggregate123774573395 after rerunning the already-green suite. PR496's initial failed aggregate124570831119 coexisted with successful124571541803; rerunning the cancelled suite (not the green suite) produced124572986532 SUCCESS and the first post-completion state was CLEAN, with no head, label or policy change. PR506 failure124650521394 coexisted with success124651117726 and did not block.

The greater suite ID is failed in the two blocked observations and successful in the CLEAN control. Run-ID ordering differs on PR477. This correlation is a hypothesis, not documentation of the selection algorithm. REST check-runs filter=latest still returns both suites' same-name checks. Historical run REST metadata only says event=pull_request: opened/labeled assignment is inferred from timelines, not proven webhook action. The dedicated follow-up experiment will log actual action explicitly and distinguish deliberate cancellation from natural concurrency cancellation.

Authority and limitations

At the blocked PR496 snapshot, main protection required only all-checks-passed, app_id=null, strict=false, zero required approving reviews; rulesets were empty, PR non-draft and mergeable, no legacy commit statuses. No policy/required-check/admin-merge bypass was used. The PR477 empty commit was an earlier workaround, not a proposed recovery; it cannot establish root cause. PR496 was not merged at the experimental head because independent code-review findings required real later changes; its CLEAN transition is not an ordinary-merge proof.

Safe operator action observed once: retain exact SHA/authority and every run/suite/check, rerun ALL jobs of the failed/cancelled suite, then recheck required status and ordinary mergeability. This is not a universal guarantee or automatic retry recommendation. We are adding a dedicated isolated same-head experiment and will append the full action/attempt/seven-job/aggregate/merge evidence here.

Question

Does protected-branch evaluation select a particular check suite for duplicate names differently from the latest successful check displayed by required-check queries? Is rerunning the affected cancelled suite the intended non-bypass recovery? What supported inspection exposes the suite actually governing the blocked merge?

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.

[DankerMu]

Isolated same-head reproduction and recovery: PR508

Dedicated PR508 adds only allowlisted event metadata and operator documentation; the existing seven jobs, always-aggregate, fail-closed script, concurrency and permissions are unchanged. Frozen source head ebffe27bcb8d0be50f645b98d9c8bc9fb77bba1c, workflow/test-merge SHA 9ecf560a6fa60c8cea6685b886e64c7c5324fd51 remained identical throughout.

Actual aggregate logs, rather than inferred REST event values, identify:

• opened: run41242594858, suite111790312284; original aggregate 124659379870.
• labeled: run41242595025, suite111790312799; original aggregate 124659800172.

The opened run was cancelled by overlapping CI. We then deliberately cancelled the live labeled run to construct the failed-newer-suite state; this is controlled fault injection, not a claim that natural concurrency always cancels the newer suite. Each event admitted all seven jobs.

Job	opened attempt1	labeled attempt1 (manual cancel)	opened attempt2	labeled attempt2
lint	cancelled	cancelled	success	success
test	cancelled	cancelled	success	success
docs-gate	cancelled	success	success	success
secrets	cancelled	success	success	success
sast	cancelled	success	success	success
pr-size	cancelled	success	success	success
profile-smoke	cancelled	cancelled	success	success
all-checks-passed	failure	failure	success	success

First intervention: gh run rerun 41242594858 (ALL jobs). Opened attempt2 completed with aggregate 124660549791 SUCCESS. With both runs completed, gh pr checks 508 --required returned exit0 and that successful check, while GraphQL returned BLOCKED / MERGEABLE. The newer labeled suite still had failed aggregate124659800172. This is the target completed required-PASS/BLOCKED discrepancy, not an ordinary pending-check block.

Second intervention: gh run rerun 41242595025 (ALL jobs of the affected failed suite). Labeled attempt2 completed with aggregate 124661508217 SUCCESS. The first completed-state snapshot now returned required exit0/PASS and CLEAN / MERGEABLE. Its log retained action=labeled, attempt=2 and the same source/workflow SHAs. No source commit, label change, protection/ruleset change, ignored cancellation, administrator override or synthetic check was used.

Protection snapshots before/after are equal: sole required context all-checks-passed, strict=false, app_id=null, zero required reviews; inherited rulesets and main branch rules are empty. Raw checks retain original failed attempts and successful reruns. Attempt-specific job lists remain queryable via /actions/runs/{run_id}/attempts/{attempt}/jobs; suite identity is not interchangeable with run or job/check ID.

Conclusion: this controlled case reproduces a GitHub multi-suite required-query/merge-state boundary, and complete rerun of the affected failed suite recovers CLEAN without refreshing SHA. It does not establish the precise undocumented selection/cache implementation or guarantee recovery for every repository. PR506 remains the natural CLEAN counterexample. Ordinary merge will be attempted only after independent review and the exact-head gate; CLEAN alone is not reported as a merge receipt.

[DankerMu]

Ordinary unchanged-head merge receipt

After three independent expanded review seats returned CLEAN and all exact-head required checks passed, the actual command succeeded:

gh pr merge 508 --merge --match-head-commit ebffe27bcb8d0be50f645b98d9c8bc9fb77bba1c --delete-branch

GitHub receipt: PR508 state MERGED, head ebffe27bcb8d0be50f645b98d9c8bc9fb77bba1c, mergedAt 2026-10-31T21:30:30Z, merge commit bb48052f3a9a9f96f2564e3db2b4788a33f9747d. No source commit was added between the blocked-state experiment, full affected-suite rerun and this ordinary non-admin merge. No policy, required context or rule was weakened; cancelled/failed/skipped dependencies still fail the aggregate.

This completes the isolated recovery proof, beyond merely observing CLEAN. The result establishes an auditable non-bypass recovery for this observed case, not a universal workaround or undocumented GitHub algorithm. The historical natural failures and natural CLEAN control remain preserved.

Upstream disposition is explicit: discussion211754 was auto-closed by the template bot because Community requires UI/template submissions. This public report and reproduction/merge evidence remain accessible, but there is no claim of active upstream acceptance, human response or service fix. Repository #479 delivers bounded diagnostics and operator guidance, not a GitHub internal patch. M3 PI acceptance is unchanged.

[DankerMu]

Additional unchanged-head recovery observation: DankerMu/SHUD-Harness PR #562.

Source head stayed 3f6ab49ce12ff07d5dfdcda2e5959400fc8eb248. Initially the required-check query reported PASS from run41509640576, but mergeStateStatus was BLOCKED and a normal merge was rejected.

Actual aggregate logs identify run41509640624 attempt1 as pull_request/labeled (suite112487141376): all seven dependencies cancelled, aggregate125497845635 failed. The successful sibling41509640576 attempt1 was pull_request/opened (suite112487141342), aggregate125499676525 successful. These actions are from recorded event metadata, not inferred from run ordering.

After preserving run/attempt/job/check/suite links and protection/ruleset snapshots, we reran the affected cancelled run41509640624 once, all jobs, without rerunning the green sibling. Attempt2 had seven successful dependencies and successful aggregate125506434304. Required PASS and mergeStateStatus CLEAN then agreed. Source head/base and protection remained unchanged; inherited rulesets/effective rules were empty before and after. No admin merge, empty commit, label toggling, or protection edits.

A normal gh pr merge --merge --match-head-commit 3f6ab49ce12ff07d5dfdcda2e5959400fc8eb248 then succeeded: MERGED at 2026-11-02T19:42:55Z, merge commit 58bb901c1c139657249ac9965bbf4a94c2035d71.

Attempt2, pre-merge evidence, actual merge receipt summary. This is one successful unchanged-head recovery, not a general guarantee or proof of GitHub's internal suite-selection algorithm.

[DankerMu]

Additional unchanged-head recovery observation: PR #568.

Frozen source/head: 6029a49e6247f2539756bbdb4f3865b07cd116a4. Base before merge: 48aaaae3e5b12f2774a2113c1216db8946836424. Initially non-draft/MERGEABLE, required all-checks-passed projection PASS, but actual mergeStateStatus=BLOCKED.

Actual logged action	Run / attempt	Suite	Seven dependencies	Aggregate
opened	41578446978 / 1	112667449801	all success	125728528264 success
labeled	41578447229 / 1	112667450442	all cancelled	125727397879 failure
labeled, manual full rerun	41578447229 / 2	112667450442	all success	125730029493 success

Actions and source SHA are from each aggregate's actual event-metadata log, not inferred from run numbering. Job check_run_url/check-run IDs were correlated with suites and source SHA. Workflow SHA 09a2ebb90d09d3f99643aeb59759347b64e65ffe was recorded separately and is not the source SHA.

After preserving run/attempt/job/check/log evidence and branch protection/rulesets, we reran only the affected cancelled run41578447229, all jobs, once (not the green sibling, not aggregate-only). Attempt2 completed; required PASS and actual CLEAN followed. Main protection and inherited/effective rules read successfully and compared identical before/after. No admin merge, empty commit, branch/rules change, label toggle, or new source SHA.

Actual normal merge receipt: gh pr merge 568 --merge --delete-branch --match-head-commit 6029a49e6247f2539756bbdb4f3865b07cd116a4 exited0; merged at 2026-11-03T04:40:08Z, merge commit 3901260ec310283fc056be3b1e493e167b593304, PR still reports the same head. Premerge evidence. Local raw artifacts: .workplans/issue-529/merge-recovery/ (not committed per project evidence policy).

This demonstrates recovery for this instance only, not a general guarantee or proof of GitHub's internal check-selection algorithm. The original cancelled and successful attempts remain part of the evidence.

[kittimzhe]

Your two unchanged-head recovery observations (PR #562, #568) map to a known state split: the required-check projection reads the best completed check runs for the head SHA (hence PASS), while the merge gate reads the check suite's aggregated conclusion — which still counts the cancelled run you identified. Same head, two different aggregations, and only the second one controls mergeStateStatus.

For forcing re-aggregation without touching the head SHA — the two levers that exist:

1. Close and reopen the PR. Reopening fires a pull_request event with action reopened on the same head; if your required-check workflows listen on pull_request (default types include reopened — unless you've narrowed them with types: [opened, synchronize]), they re-run fresh and the suite re-aggregates. This is the cheapest lever and matches your "eventually unblocked" observations — something re-triggered the suite in those cases.
2. Re-run the cancelled run: POST /repos/DankerMu/SHUD-Harness/actions/runs/{run_id}/rerun-failed-jobs (or the UI's Re-run button on that run) — a new attempt on the same head SHA, and the suite conclusion recomputes with it.

If neither is available (workflow narrowed, run record deleted), the fallback is the one you've been avoiding — any new commit to the head, via the update-branch button — which recreates the suite by definition. Worth logging which lever works in each case, since your observations are the best dataset on this family so far.