Replies: 2 comments
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
|
I am seeing the same issue on another account. Two workflow runs created on November 11, 2026 at about 20:24 UTC are still queued with zero jobs. A cancellation attempt returned HTTP 409: "Cannot cancel a workflow run that has not been queued yet." I contacted GitHub Support, but the ticket was closed with a direction to self-service resources, including Community Discussions. Is there a supported way to recover these stuck runs, or an escalation path for accounts in this situation? |
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Bug
💬 Feature/Topic Area
Workflow Deployment
Discussion Details
Discussion Type
Bug
Feature/Topic Area
Workflow Deployment
Discussion Details
Resubmitting discussion #212707, which was closed because it was not created through the required UI template.
The original report describes two manually dispatched runs stuck in
queuedwith zero jobs:.github/workflows/build.ymlAccording to that report, normal cancellation says the first run is completed, while force-cancel returns HTTP 409 saying it has not been queued yet. Subsequent queries still show
queued. The workflow reportedly has no concurrency group or deployment environment.I have independently encountered the same pattern: a run reports
queued, has zero jobs and no pending deployment approvals, and both cancellation endpoints return HTTP 409:GitHub’s troubleshooting documentation describes these symptoms as potentially indicating an abnormal or out-of-sync run.
Is there a supported recovery procedure after both cancellation endpoints fail, or must GitHub Support reconcile the run? What is the appropriate private escalation channel for affected run identifiers?
All reactions