Unlocking Stuck GitHub Actions Runs: A Community Guide to Orphaned GitHub Activities
The Case of the Permanently Queued GitHub Action
In the world of continuous integration and delivery, GitHub Actions are the backbone of many development workflows. However, like any complex system, they can sometimes encounter glitches. A recent discussion on the GitHub Community forums highlighted a particularly frustrating scenario: a GitHub Actions run stuck in a 'Queued' state, defying all attempts at cancellation or deletion. This insight from devactivity.com explores the problem, the community's analysis, and the ultimate solution for dealing with these orphaned github activities.
The Frustrating Freeze: A Run That Wouldn't Budge
User MYLEGND reported a GitHub Actions run for their masterapp repository that had been 'Queued' for weeks. Standard cancellation and force-cancellation attempts returned an HTTP 409 Conflict error, with a message stating the run 'has not been queued yet'—a direct contradiction to its visible status. Deletion attempts were met with an HTTP 403 Forbidden, 'Could not delete the workflow run'. This left MYLEGND with a stale record and no clear path forward, especially since their GitHub Free account didn't offer technical support for Actions issues.
Community Dissection: Why It Wasn't a Blocking Issue
The community quickly jumped in to analyze the situation. As Sagargupta16 pointed out, despite its 'Queued' status, the run had 0 jobs and no concurrency key in its workflow file. This meant it wasn't actually blocking any subsequent github activities, nor was it consuming runner resources or incurring billing. The 409 error on cancellation made sense in this context: cancellation acts on jobs, and this run never had one. This clarified that the issue was a 'stale record' rather than an active blocker.
A critical piece of information also emerged regarding support: GitHub's troubleshooting guide directs users to Support for stuck runs, but technical support for Actions is not included with Free accounts. This explained why MYLEGND couldn't open a technical ticket, highlighting a common challenge for users on different GitHub plans.
The Breakthrough: Deleting Orphaned Runs
The definitive solution came from kittimzhe, who identified the run as a 'fully-orphaned variant' or a 'lost queue event'—a run object created, but never picked up by the scheduler, evidenced by its frozen created_at and updated_at timestamps. The key insight was GitHub's documented rule allowing deletion of workflow runs that are 'completed or more than two weeks old'. Since MYLEGND's run was 26 days old, the self-serve deletion path was now available.
The recommended steps, verified via API, were:
Attempt cancellation (for the record, it will likely still fail):
POST /repos/MYLEGND/masterapp/actions/runs/37642351262/cancelExecute deletion (this is the one that works for old, orphaned runs):
DELETE /repos/MYLEGND/masterapp/actions/runs/37642351262
This API call successfully removes the stuck run from the list, resolving the issue.
Key Takeaways for Your GitHub Activities
- Identify the Type of Stuck Run: Distinguish between a run that's genuinely blocking resources (e.g., via concurrency groups) and an orphaned record that's merely a visual anomaly.
- Understand Support Tiers: Be aware of the technical support limitations based on your GitHub account plan. Free accounts have restricted access for technical issues.
- Leverage the Two-Week Rule: For orphaned github activities that are more than two weeks old, the API deletion method is a powerful self-serve solution.
- Use Specific Terminology for Escalation: If you do have access to GitHub Support and need server-side investigation for similar issues, referring to it as a 'lost queue event' can help route your ticket correctly.
This community insight demonstrates the power of shared knowledge in navigating the complexities of modern development platforms and ensuring smooth github activities.
