Actions run queued with zero jobs; cancellation returns HTTP 409

[alictsay-prog]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Other

Discussion Details

An Actions run remains queued with zero jobs, while cancellation returns HTTP 409: “Cannot cancel a workflow run that has not been queued yet.” The workflow is disabled. How can GitHub staff confirm whether this run can still create jobs? Private identifiers can be provided through an authorized private channel.

[github-actions[bot]]

💬 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 ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

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. ⭐

[ssuleimenovv]

Hi

I've seen runs get stuck like this. Here is what usually gets them unstuck. Since the workflow is already disabled, these are safe to try:

1. Force-cancel instead of a normal cancel

The regular cancel endpoint rejects runs that never reached the queued state. There's a separate endpoint that skips that check:

POST /repos/{owner}/{repo}/actions/runs/{run_id}/force-cancel
It needs a token with actions: write (or a classic PAT with repo). With the CLI:

gh api -X POST repos/{owner}/{repo}/actions/runs/{run_id}/force-cancel

2. If force-cancel also fails, delete the run

DELETE /repos/{owner}/{repo}/actions/runs/{run_id}
Or click "Delete workflow run" in the run's ... menu. Once it's deleted, nothing can create jobs for it anymore. You lose the run history, but with zero jobs there isn't much to lose.

3. Checking whether it can still create jobs

From the outside, the best signal is to poll:

GET /repos/{owner}/{repo}/actions/runs/{run_id}
GET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs?filter=all
If status stays queued, jobs stays empty, and updated_at doesn't move, the run is effectively orphaned. Disabling the workflow blocks new runs from being triggered, but as far as I know it doesn't officially guarantee anything about a run that already exists in a broken state. Only GitHub can confirm that from their side.

[alictsay-prog]

Update: I attempted the official force-cancel endpoint once using an authenticated GitHub CLI.

The request reached GitHub but returned HTTP 409:

"Cannot cancel a workflow run that has not been queued yet."

A subsequent read-only check still shows:

• Status: queued
• Conclusion: null
• Run attempt: 1
• Jobs: 0
• Updated_at: unchanged since October 7, 2026

Could GitHub staff investigate this inconsistent backend state or recommend a safe way to ensure the run can no longer create jobs?

I can provide private run identifiers and the GitHub Request ID through an authorized private channel.

[ssuleimenovv]

Thanks for trying it and for the follow-up details. A 409 from force-cancel plus queued / 0 jobs / updated_at frozen since Oct 7 does look like an inconsistent backend state, not something the workflow settings can affect.

The next step I'd try is the one that wasn't tested yet: deleting the run.

gh api -X DELETE repos/{owner}/{repo}/actions/runs/{run_id}

(or "Delete workflow run" in the run's ... menu). If it succeeds, the run no longer exists, so it can't create jobs later. I can't promise the API accepts it for a run that never completed, so if it also returns an error, please include that response in the next step below.

For a definitive answer about whether this run can still create jobs, only GitHub can say. Community Discussions are mostly peer-to-peer, so the reliable private channel for your run ID and X-GitHub-Request-Id is a ticket at support.github.com. I'd include:

• the run ID and repo
• the 409 response from force-cancel (and from delete, if you try it)
• that the workflow is disabled and updated_at hasn't changed since Oct 7

If deleting the run works, please mark this as the answer so others with a stuck queued run can find it.

[alictsay-prog]

Thanks for the suggestion. I tried the DELETE endpoint once using an authenticated GitHub CLI.

Unfortunately, GitHub returned:

HTTP 403 Forbidden
"Could not delete the workflow run."

Here are the results so far:

• Normal cancel: HTTP 409
• Force-cancel: HTTP 409
• Delete workflow run: HTTP 403
• Run status: queued
• Run attempt: 1
• Jobs: 0
• Updated_at: unchanged since October 7, 2026

I have stopped further cancellation and deletion attempts to avoid making the situation worse.

My GitHub Support portal currently shows "Technical support not included", so I cannot open a private technical support ticket.

Is there another way to escalate this issue to GitHub staff, or safely confirm that the stuck run cannot create jobs in the future?

I can provide the repository, run ID, and GitHub Request IDs through an authorized private channel.

Thank you for your help.