Actions run stuck queued with zero jobs; cancel and force-cancel return 409

[MrAlvaro2U]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Other

Discussion Details

Summary

I appear to have an orphaned / internally inconsistent GitHub Actions workflow run in a production repository.

The public Actions API reports the run as queued, but the run has zero jobs and zero check runs, and both the normal cancel endpoint and the official force-cancel endpoint return HTTP 409 saying that the workflow run has not been queued yet.

Because I cannot determine whether this old run could unexpectedly materialize later, I have disabled the production workflow. This is currently stopping a periodic data-collection workflow and causing gaps in production historical data.

Repository and affected run

• Repository: MrAlvaro2U/dolarbolivia-widget
• Workflow: Actualizar precio del dólar
• Workflow path: .github/workflows/update_dolar.yml
• Workflow ID: 168933053
• Run ID: 33456680954
• Run number: 140254
• Run attempt: 1
• Event: workflow_dispatch
• Branch: main
• Head SHA: c98439160f855445a4def820138dec1e92dbf321
• Check suite ID: 90658196634

Observed state

The public Actions API reports:

• status: queued
• conclusion: null
• run_attempt: 1
• previous_attempt_url: null
• created_at: 2026-09-01T00:55:10Z
• run_started_at: 2026-09-01T00:55:10Z
• updated_at: 2026-09-01T00:55:10Z

All timestamps have remained frozen at the creation time.

However, the run has:

• 0 jobs
• 0 check runs
• 0 artifacts
• 0 pending deployments
• no workflow steps ever executed

The associated check suite also remains queued with conclusion: null, but contains zero check runs.

This looks like the workflow-run/check-suite records were created, but no actual job/scheduler workload was created.

Cancellation behavior

I first attempted normal cancellation using GitHub's official Actions API.

It returned:

HTTP 409 Conflict

indicating that the workflow run had not yet been queued.

I then made exactly one request to the official force-cancel endpoint:

POST /repos/MrAlvaro2U/dolarbolivia-widget/actions/runs/33456680954/force-cancel

It also returned:

HTTP 409 Conflict

with the exact message:

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

Force-cancel request ID:

9721:3C9755:30E67C3:C7EC18D:6A965F78

No retry or alternative mutation was attempted afterward.

This seems internally contradictory:

• Run API: queued
• Check suite: queued
• Jobs: 0
• Check runs: 0
• Normal cancel: run has not been queued yet
• Force-cancel: run has not been queued yet

Additional diagnostics

I verified that:

• the referenced production commit still exists
• the referenced workflow revision still exists
• GitHub Actions is permitted for the repository
• the repository's default workflow token permission is write
• the workflow is currently disabled_manually
• there are no newer active production runs
• this orphaned run is the only active production workflow run
• re-enabling the workflow previously did not cause this run to materialize
• no jobs or check runs appeared after re-enabling
• the run timestamps did not advance

I also reproduced the same workflow successfully in a separate disposable repository. The workflow completed normally there, including the scraper, validation, commit and normal push.

This suggests that the workflow definition itself is not inherently unable to execute.

Production impact

This workflow periodically collects a USD/Boliviano exchange-rate observation and appends it to historical JSON data used by an application.

I have disabled the production workflow because I cannot establish whether this orphaned run could unexpectedly materialize later and execute its old workflow revision.

As a result, production price-history collection is currently stopped and historical observations are being lost while this issue remains unresolved.

Data integrity checks

Before and after the cancellation attempts I verified that:

• production main SHA did not change
• production gh-pages SHA did not change
• dolarbolivia.json did not change
• historial_dolarbolivia.json did not change
• no newer production workflow run was created

Therefore, the diagnostic and cancellation attempts did not modify production data.

What I need help with

Could someone from GitHub please help determine whether this is an orphaned Actions scheduler/control-plane record?

Specifically:

1. Does any scheduler-side workload/event still exist for run 33456680954?
2. Can this run ever materialize into a job despite currently having zero jobs/check runs?
3. Can the orphaned run/check-suite be reconciled to a terminal cancelled/completed state or purged server-side?
4. Is it safe to re-enable the production workflow without this old run executing later?

If this requires internal GitHub investigation rather than community troubleshooting, I would appreciate it if this report could be escalated to the appropriate GitHub Actions team.

I can provide the complete REST API responses and additional diagnostics if needed.

Thank you.

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

[nirav-gajera]

Your diagnostic work is thorough and the contradiction is real — this isn't a user-side issue, this is a genuine orphaned record on GitHub's backend.

The core problem: the workflow-run and check-suite records were created in the API/metadata layer, but the job-scheduler never actually got a workload to process. So:

• API reports status: queued (based on what the metadata says)
• Cancel endpoints return "run has not been queued yet" (based on the scheduler's actual state)
• Jobs: 0, check runs: 0 (because nothing ever hit the scheduler)

This is exactly the kind of split-brain record that can't be fixed from the user side — the scheduler and metadata layers disagree on whether a workload actually exists.

Your original instinct to disable the workflow was correct — until this is cleared, re-enabling could theoretically cause unexpected behavior if that orphaned record suddenly materializes. Better safe than having a stale run execute old code on production.

This needs GitHub staff investigation. Community discussions can't access the scheduler layer to see if a workload actually exists or to manually purge it. File a formal report with GitHub Support and reference this discussion — include:

• Run ID: 33456680954
• The HTTP 409 response from force-cancel (you have the request ID: 9721:3C9755:30E67C3:C7EC18D:6A965F78)
• The internal contradiction (API says queued, scheduler says not queued)
• Screenshot showing 0 jobs / 0 check runs despite queued status
• Note about production data collection being blocked

This is exactly the type of case that needs staff with backend access — they can query the scheduler state directly, determine if there's a stuck workload, and either force-complete or purge the orphaned record.

Until then, keeping the workflow disabled is the right call.