Orphaned Actions run queued with 0 jobs; force-cancel returns 409

[QuintonGoh]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Summary

A GitHub Actions workflow run created during the August 26, 2026 Actions incident is stuck in an inconsistent pre-dispatch state.

The REST API reports the run as queued, but no job was ever created. Both the web UI cancellation and the documented force-cancel endpoint fail.

Affected run

• Repository: QuintonGoh/quant-research (private)
• Run ID: 32985299253
• Run URL: https://github.com/QuintonGoh/quant-research/actions/runs/32985299253
• Workflow: factor-algorithm-ci
• Event: push
• Branch: main
• Head SHA: a41af9bb9c6da7f1de696edb4839ff77bda2dd5c
• Created: 2026-08-26T15:29:52Z
• Last updated: 2026-08-26T15:29:52Z
• Run attempt: 1

Observed state

status=queued
conclusion=null
jobs.total_count=0
updated_at == created_at

The run has remained unchanged for more than 24 hours.

The web UI reports:

Failed to cancel workflow.

The documented force-cancel endpoint returns:

HTTP 409 Conflict
Cannot cancel a workflow run that has not been queued yet.

This contradicts the REST run state, which reports status=queued.

The force-cancel endpoint was inadvertently invoked twice while capturing the HTTP response. Both requests returned the same 409 response, and the run state did not change.

Isolation evidence

• Actions are enabled for the repository.

• The workflow is active.

• No environment approval is pending.

• There are no other queued or in-progress repository runs.

• Both main and the source branch point to the same SHA.

• The identical SHA completed successfully on the source branch 36 minutes earlier:

  • Run ID: 32983040904
  • Conclusion: success
  • 11/11 steps succeeded
  • 531 focused tests passed

• GitHub Actions currently reports operational status.

This indicates that the affected record exists in the API/UI but was never submitted to the Actions scheduler.

Impact

The orphaned run blocks exact-SHA CI evidence for the main branch. It cannot be cancelled or rerun, although the identical code and workflow already passed on the source branch.

No code change, empty commit, re-push, workflow dispatch, or alternative CI trigger has been performed.

Requested help

Please:

1. Reconcile or purge workflow run 32985299253 server-side.
2. Confirm that the orphaned run cannot unexpectedly execute later.
3. Transition it to completed/cancelled, if possible, so it can be rerun once using the original push event and SHA.
4. Confirm whether other workflow runs created during the August 26 Actions incident were left in the same inconsistent pre-dispatch state.

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

[Totalwally]

This looks consistent with the August 26 Actions incident rather than a problem with your workflow configuration.

GitHub’s incident report says that some workflow runs triggered during the 15:02–15:45 UTC incident window were left showing as queued after service recovery, even though the runs had already failed in the backend. GitHub also says those affected runs would automatically transition to cancelled 24 hours after creation.

That matches the state you're seeing unusually well: queued, no jobs, unchanged timestamps, and the force-cancel endpoint returning 409. The API does document force-cancel as the mechanism for runs that aren't responding to normal cancellation, but a 409 is a documented possible response, so it doesn't provide a workaround for this particular orphaned state.

Given that your run was created during the incident window, I'd wait for the 24-hour automatic transition described in GitHub's incident report rather than trying to manipulate the workflow further. If it remains stuck beyond that window, I'd report the run ID to GitHub Support and reference the August 26 incident.

One other detail: I wouldn't expect this run to suddenly start executing after recovery if it is one of the affected backend-failed runs described in the incident report. GitHub specifically says those runs had already failed in the backend and would be transitioned to cancelled.