Actions runs stuck queued with zero jobs; cancel/force-cancel 409, rerun 403

[Dytschgo]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Actions Runner

Discussion Details

Repository: https://github.com/Dytschgo/imnota (public)
Repository administration permissions have been verified; no permission error is reported by cancellation.

Please reconcile or clear these four stuck runs so CI for PR #214 can execute:
https://github.com/Dytschgo/imnota/actions/runs/43097671914 (Validate, current head)
https://github.com/Dytschgo/imnota/actions/runs/43097672012 (CodeQL, current head)
https://github.com/Dytschgo/imnota/actions/runs/43095513168 (Validate, superseded head)
https://github.com/Dytschgo/imnota/actions/runs/43095513030 (CodeQL, superseded head)

PR: Dytschgo/imnota#214
Current head: 40d9c860ad7f6886f71f4225dc912a7b9ab3bb11
Superseded head: 3b4d41cabbc240ed4d51b1fda09a486df6383769

The runs have remained queued since November 11, 2026. The current Validate run reports attempt 1, null conclusion and zero jobs; its updated_at remains 2026-11-11T20:42:56Z. There are no in-progress runs in this repository. The repository is enabled, and both workflows have normal pull_request triggers.

Normal cancellation and force-cancellation were each attempted against all four runs:
POST /repos/Dytschgo/imnota/actions/runs/{id}/cancel
POST /repos/Dytschgo/imnota/actions/runs/{id}/force-cancel
Both returned HTTP 409: Cannot cancel a workflow run that has not been queued yet.

One rerun of current Validate was attempted:
POST /repos/Dytschgo/imnota/actions/runs/43097671914/rerun
It returned HTTP 403: This workflow is already running.
The GitHub UI also does not allow the owner to clear the runs.

GitHub reported an Actions incident on November 11; the status API now reports Actions operational. We cannot establish whether the incident caused these records. A later scheduled nightly on the existing main revision completed successfully, while these PR runs remain stuck.

Can GitHub staff inspect these run/check-suite records or advise a supported recovery procedure? Current Validate check_suite_id: 116712006352.

Desired recovery: start exactly one fresh Validate execution for the current PR head first; run the remaining required security checks afterward before any merge. Do not bypass protections or mark unexecuted checks successful.

No branch protections, workflow triggers, billing settings or source files were changed to work around this issue. We have not deleted run history or published the PR changes. The exact candidate already passed local Windows tests and native verification; hosted platform/security checks are still required before merge.

I found similar reports, including https://github.com/orgs/community/discussions/210234. GitHub's troubleshooting guide describes this zero-job/409 state and recommends contacting Support: https://docs.github.com/en/actions/how-tos/troubleshoot-workflows#canceling-workflows . The private support route directed me to Community. Is there a supported way for GitHub staff to reconcile these run/check-suite records without bypassing required checks?

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

[kaluarachchiteshan]

Hi,

Your write-up matches what other users reported for runs created around the November 11 incident. The 409 ("has not been queued yet") on cancel and force-cancel, together with the 403 ("already running") on rerun, suggests the run record exists but was never fully initialized on the backend. In that state the public API can't cancel it (never started) and can't rerun it (never finished). Community members can't repair that record, but here is what is worth trying without changing protections, triggers or source.

1. Try deleting the stuck runs through the API

The UI may not offer it, but the API sometimes does:

gh api -X DELETE repos/Dytschgo/imnota/actions/runs/43097671914

Repeat for the other three run IDs. This may be refused for runs that are not completed. If it works, it removes only the run record, not the PR, checks history you care about, or code. Note that deleting does not by itself start a new run.

2. Start a fresh run on the same head commit, without a new commit

• Close and reopen PR #214. Default pull_request triggers include opened, synchronize and reopened, so reopening normally starts new runs for the current head (40d9c86). Check that your workflows don't restrict types: to exclude reopened.
• Manual dispatch, if either workflow has workflow_dispatch::

gh workflow run <validate-workflow>.yml --ref <pr-branch>

A manual run does not report as the PR's required check in all configurations, so use it as a test of whether runners start at all.

If the old stuck runs share a concurrency: group with the new ones, they can block them. In that case, delete or clear the stuck runs first.

3. Required checks and merge protections

You don't want to bypass anything, which is the right call. A manually dispatched run on the same SHA generally does not satisfy a required check tied to the pull_request event, so wait for the reopened PR's runs and merge only after the required checks report success.

4. Escalate with the specifics

Because the documented troubleshooting page says to contact Support for this state, and Support sent you here, ask for a human review on the existing ticket or open a new one at https://support.github.com/contact. Include:

• repository Dytschgo/imnota and PR #214
• the four run IDs and the check suite ID 116712006352
• head SHAs 40d9c860ad7f6886f71f4225dc912a7b9ab3bb11 and 3b4d41cabbc240ed4d51b1fda09a486df6383769
• the 409 response for cancel and force-cancel, and the 403 for rerun
• that runs have been queued since 2026-11-11T20:42:56Z with zero jobs
• a link to the troubleshooting section you cited and to discussion Workflow run stuck "queued" for 6+ days: cancel says "completed", force-cancel fails, delete returns 403 #210234

State clearly that you want the check suite and run records reconciled or cleared, with no required checks bypassed.

5. Don't mark anything as passing

Don't use workarounds such as a status posted through the API, or a protection change, to make required checks green. Your plan (fresh Validate first, then the security checks, then merge) is the right order.