Ghostly GitHub Actions Reruns: A Challenge to Git Quality and CI/CD Reliability
GitHub Actions is a cornerstone of modern CI/CD, but what happens when a workflow run gets stuck in an inexplicable limbo, defying cancellation and casting doubt on your git quality? A recent discussion in the GitHub Community highlights a particularly frustrating scenario: "ghost" GitHub Actions reruns that remain perpetually queued with zero jobs, creating significant headaches for developers.
The Phantom Rerun: A State of Contradiction
The core of the problem, as detailed by user toddbuono-ship-it, revolves around a pull_request workflow rerun that became orphaned around a GitHub Actions incident. Despite the GitHub UI and REST API reporting the run as queued with a status=queued and c>, a closer inspection reveals a critical inconsistency: the jobs API shows total_count=0 and jobs=[]. This means the run exists in name, but has no actual work associated with it.
Attempts to resolve this state prove futile:
- Cancelling via the REST API (
POST /actions/runs/32984842480/cancel) returns an HTTP 409 error, stating "Cannot cancel a workflow re-run that has not yet queued." This is paradoxical, given the run is reported as queued. - Using the GitHub CLI (
gh run cancel 32984842480) yields an equally confusing message: "Run is completed," directly contradicting the UI and API.
This leaves developers in a perplexing situation where official tools and interfaces offer conflicting information, making it impossible to determine the true state of their CI pipeline. The user emphasized that no source, commit, or repository state had changed, and no duplicate rerun was submitted, indicating a system-level anomaly.
Impact on Development KPIs and Git Quality
Such orphaned runs have a tangible impact on development workflows and can skew development kpi metrics. For teams relying on exact-head reviews for governance, a stuck workflow run prevents further progress on that specific commit SHA. The inability to clear or even confidently ignore these ghost runs introduces uncertainty and potential delays. Developers are left wondering:
- Can GitHub intervene server-side to clear these runs?
- Is there a self-service method for repository owners to force-cancel or delete them?
- Is it safe to submit a fresh workflow run against the exact same unchanged head, or does this risk duplicate execution if the ghost run mysteriously materializes later?
These questions highlight a critical gap in current GitHub Actions management tools, especially concerning edge cases stemming from platform incidents. The uncertainty directly affects the perceived reliability and git quality of the CI/CD pipeline, as build statuses cannot be trusted.
Community Seeking Answers, But Finding None
The original post, seeking guidance, was unfortunately closed by an automated reply, directing the user to re-submit via a template. This further underscores the challenge users face when encountering novel or complex issues that fall outside predefined support pathways. While related discussions (#204255, #202511, #204218) acknowledge similar scheduler/API mismatches, official guidance on self-service resolution or the safety of re-running workflows remains elusive.
This incident serves as a reminder of the need for robust troubleshooting mechanisms and clear documentation for managing CI/CD anomalies. Ensuring the integrity of workflow states is paramount for maintaining high git quality and developer trust in automated processes.
