Quick Answer
The MCP servers repository has moved a newer-run check ahead of result classification in its Python and TypeScript CI workflows. When that check finds a later dispatched run for the same workflow and commit, the older run exits without publishing a commit status, regardless of whether its jobs passed, failed, or were cancelled.
PR #5179 merged on October 19, 2026. The change addresses which run may report a result; it does not change the underlying job results. Its protection also depends on the newer-run lookup succeeding.
In Plain English
Consider two manual CI dispatches against the same commit. Run A starts first, encounters a failed job, and reaches its reporting step after Run B has started. Both runs can publish to the shared commit-status context.
Before this patch, Run A classified its failure before checking whether a newer dispatch existed. It could therefore publish failure even though Run B had taken over the work. The older guard only protected the branch handling cancellation and other remaining results.
After the patch, Run A first asks whether a later dispatch exists. If one is found, it stops reporting. The same rule now covers successful, failed, and cancelled result sets. Run A’s failure remains part of its own execution history, but that result no longer authorizes it to update the shared status after the guard detects a replacement.
Code Evidence
The pull request and official PR metadata identify the merged change. The merge diff and commit metadata establish the comparison with its first parent.
In the pinned Python workflow, the lookup filters for workflow_dispatch runs of python.yml on GITHUB_SHA. It counts database IDs greater than GITHUB_RUN_ID. A positive count triggers an early exit before status selection or the status-posting API call. Previously, that lookup sat inside the final result branch.
The pinned TypeScript workflow makes the equivalent move for typescript.yml. With no newer run found, it retains the existing classification: all successful or skipped jobs produce success, any failed job produces failure, and the remaining cancellation case produces error.
The pinned test file extracts each workflow’s actual reporting script and executes it under Bash with a stub GitHub CLI. For a newer-run count of one, failed, passed-or-skipped, and cancelled inputs must produce no status. For zero, those inputs must produce failure, success, and error respectively. The behavioral cases skip on Windows or when Bash or jq is unavailable.
GitHub’s workflow documentation supplies the event-trigger context. The repository’s v2.0.0 release record associates that release with separate merge #5166; it does not establish a package release for this fix.
Why It Matters
A commit status compresses a run’s detailed execution into a small signal that reviewers can act on. When multiple runs share that reporting destination, completion order can otherwise determine which result people see.
This patch makes the replacement check apply consistently across result categories. A superseded failure is no longer treated as more entitled to report than a superseded cancellation. That matters when a reviewer is deciding whether a fresh dispatch has finished or whether an older result is still visible.
The distinction is between a valid historical result and a result that should currently represent the commit. Keeping those concepts separate makes the reporting behavior easier to reason about, without claiming that the newer run will succeed.
An Open Question
When gh run list fails, should the status job continue publishing the current run’s result, or treat the lookup failure separately?
The implementation assigns NEWER=0 on lookup failure and continues into result classification. That permits reporting even though the script has not established whether a newer dispatch exists. The accompanying comment explains a preference for reporting over leaving a status pending, but the fallback does not prove that any particular status would remain pending.
A regression case that makes the stubbed lookup fail, together with maintainer confirmation of the desired policy, would resolve the remaining question. The supplied harness only simulates successful lookups.
Scope and Limitations
This report uses the supplied official diff and corrected research, with a source-check date of October 20, 2026, KST. No exact check time is claimed. The tests were inspected, not independently executed, and no overlapping live dispatches were reproduced.
PR #5179 reports 13 targeted cases passing, a successful local gate, and 41 passed checks. Those are upstream reports. This is a CI-only change with no identified separate package release or client-visible surface. It establishes a specific reporting guard, not a universal guarantee about CI ordering or every possible status update.