Actions run remains queued with zero jobs; cancel, force-cancel and deletion fail

[hoopsenglish]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Other

Discussion Details

A private repository on a GitHub Free personal account has a manually dispatched Actions workflow run that has remained queued for more than three weeks. Its check suite also remains queued with no conclusion.

Current REST observations:

• Zero jobs across all attempts, check runs, artifacts and pending deployments.
• Normal cancellation and force-cancellation both return HTTP 409: “Cannot cancel a workflow run that has not been queued yet.”
• The documented age condition for deletion is met, but deleting this single empty run returns HTTP 403: “Could not delete the workflow run.” The authenticated account has repository admin permissions.
• The web interface also reports “Failed to cancel workflow” and offers no deletion action for this run.
• The per-run concurrency list is empty and the production concurrency group is inactive. Newer workflows have executed, but we cannot treat that as proof the old publisher can never start.

GitHub's troubleshooting guidance describes this zero-job/cancellation-error pattern as potentially out of sync and recommends Support. The authenticated Support portal says technical support is not included and does not offer an Actions technical case for this Free account.

Is there a supported way to have GitHub reconcile or terminally cancel this malformed run/check suite? Can a GitHub staff member provide an appropriate private channel for the exact run identifiers? We want to preserve the repository, history and unrelated runs and prevent an obsolete publisher from ever starting. We are not asking to rerun it, disable required checks, or bypass the state.

Private repository names, run IDs, logs and credentials are intentionally omitted from this public question.

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

[NexzaDev]

Hi @hoopsenglish,

Thanks for the thorough write-up. Here's what I can add from the documentation, plus a few ways to reduce the risk while you wait for GitHub to fix this.

1. Your observations match the documented "stuck run" state

GitHub's troubleshooting guide describes a run that stays queued or in progress after cancellation attempts as possibly stuck in an abnormal state. The signs it lists include no jobs being created, "Failed to cancel workflow" in the UI, and the cancel or force-cancel endpoints returning HTTP 500 or 409. It also says self-service cancellation, including force-cancel, may not clear a stuck or out-of-sync run or check suite, and that you need to contact the GitHub Support portal to have it cleared.

2. Why the deletion failure is a useful data point

The docs say a workflow run can be deleted if it has completed or is more than two weeks old, and that write access is required. Your run is well past two weeks and you have admin access, so the 403 supports your reading that the run is in an inconsistent state and not that you're missing a permission. I'd mention this explicitly in any ticket, along with the exact error text of each response.

3. Making sure an obsolete publisher can't do any harm

Since the run has no jobs, there's nothing executing today, and I can't tell you whether it could ever start. If your main concern is that a stale publish run might someday run, you can reduce the impact without touching the run itself:

• Make the workflow safe by design: add a guard condition on the publish job (for example, only run for a specific ref or input), or require approval through a protected deployment environment.
• Rotate or revoke the credentials the publisher uses (tokens, deploy keys, registry secrets) and remove them from the repository or environment secrets. A run without valid credentials can't publish anything.
• If the workflow is no longer needed, you can disable it or remove its workflow_dispatch trigger in a commit. I'd check first how this affects the stuck run, as I haven't verified it, and I understand you'd rather not change workflow state, so treat this as optional.

4. Getting it in front of GitHub

I can't speak for GitHub or promise a response. Options I'm aware of:

• Submit a ticket at https://support.github.com. I can't confirm which categories are offered to a Free account, but the documentation itself points to that portal for this issue, so describing it there and quoting the guidance may help. If the form only offers account or billing categories, choose the closest one and state clearly that it's an Actions control-plane problem.
• Keep this discussion updated. It carries the Bug label, and staff do read it, although there's no guaranteed response time.
• Another thread today (Workflow queued with no jobs; cancel and force-cancel both return HTTP 409 #211243) reports a very similar stuck run with the same Support limitation, which may help GitHub see it's not an isolated case.

5. What to prepare for a private channel

Since you've kept identifiers out of this post, prepare them now: the repository name, the run ID and check suite ID, the exact timestamps (when the run was dispatched and when you first noticed it), the full response bodies for the 409 and 403 calls, and the request IDs from the response headers if available.

Hope this helps, and please post back if you find a route that works.