Workflow run stuck "in_progress" indefinitely; job finished but run never closes, Cancel workflow fails

[todozhop-cmd]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Repo: seismik-org/seismik (public)
Run: https://github.com/seismik-org/seismik/actions/runs/36802223497 (CI #170, workflow ci.yml, push to main, commit f30c351)

The ios job's last step ("Complete job") reports completed/success at 2026-10-01T02:00:38Z (confirmed via GET /repos/seismik-org/seismik/actions/jobs/110178858154). Despite that, both the job and the parent run still report status=in_progress with no conclusion, and the UI still shows the job spinning, now past 1h10m.

Clicking "Cancel workflow" in the UI returns: "Cannot cancel a workflow run that is not in progress." The "..." menu offers no re-run option while the run is in this state, so there is no UI path to recover it. Three downstream jobs (deploy-api, deploy-workers, deploy-web) are gated on this job via needs: and are stuck waiting indefinitely.

Worked around by pushing an empty commit to start a fresh run (https://github.com/seismik-org/seismik/actions/runs/36807560999), but the original run (#170) is still stuck and, as far as I can tell, has no way to be cancelled or cleaned up from the UI or the unauthenticated REST API.

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

[kittimzhe]

One unexplored path: you tried the unauthenticated REST API, but both recovery endpoints work authenticated against your own repo with a PAT (repo scope):

POST   /repos/seismik-org/seismik/actions/runs/36802223497/cancel
DELETE /repos/seismik-org/seismik/actions/runs/36802223497

• The cancel call may still return the same 409 "Cannot cancel a workflow run that is not in progress" — the state machine that lost your job-completion event is the same one evaluating cancellability — but it's worth confirming authenticated, since your unauthenticated request never reached the state check.
• If cancel refuses, try DELETE the run: it clears a run (and its waiting downstream jobs) from the list, which is the closest thing to the cleanup you were looking for. Whether it accepts an in_progress run whose job already reports completed is exactly the test that documents the bug — if it 409s too, the run is genuinely stuck outside support.

For the support report, your diagnosis is already the complete one — this is a lost job-completion event: the runner finished (jobs/110178858154 shows completed/success at 02:00:38Z) but the completion never reached the run orchestrator, so the run never transitions out of in_progress. Two attachments make it actionable:

• the job's completed_at vs. the parent run's still-spinning state (the smoking gun),
• your empty-commit run 36807560999 succeeding normally — that isolates the fault to run 36802223497's state record rather than the repo, workflow, or runner.

[zjch022]

I'm experiencing a similar issue in zjch022/gongjuzhan, PR #40.

Affected run: 36803191551
Affected job: 110181843943 — pdf-ui-browser (webkit)
Head SHA: 3cd5289ee6327bfae97b17c0b921808059ba3bea

The WebKit job logs show:

• 20 tests passed.
• Artifact upload completed and finalized.
• Post-job cleanup completed.
• “Complete job” reports success.

However, the API still reports:

• Run: in_progress, conclusion: null
• Job: in_progress, conclusion: null, completed_at: null

We attempted recovery using an authenticated GitHub CLI:

• Cancel: HTTP 409 — “Cannot cancel a workflow run that is not in progress.”
• Force cancel: HTTP 409 — same message.
• Delete run: HTTP 403 — “Could not delete the workflow run.”

A separate manually triggered run, 36815485141, on the exact same Head SHA completed successfully:

• Chromium: 20 passed, completed/success
• WebKit: 20 passed, completed/success
• Overall run: completed/success

The original pending WebKit check remains on the PR. We have preserved the job logs and artifacts and have not changed code or merged the PR.

Could GitHub staff investigate this apparent inconsistency between the reported run state and the cancellation endpoints, and help finalize the original run/check?

Original run: https://github.com/zjch022/gongjuzhan/actions/runs/36803191551
Successful manual run: https://github.com/zjch022/gongjuzhan/actions/runs/36815485141

The repository is private, so these links may not be accessible to community members.

[Shiba-0101]

We are seeing the same run-state inconsistency in another repository. Could GitHub staff investigate and reconcile the original run/check to its correct terminal state? Please do not rerun it or delete its history.

Repository: Shiba-0101/yukkuri-rankings
Workflow: Production collection jobs
Affected run: https://github.com/Shiba-0101/yukkuri-rankings/actions/runs/36803252795
Affected job: https://github.com/Shiba-0101/yukkuri-rankings/actions/runs/36803252795/job/110182036130
Commit: fb4e9064b446835e4b253294d76f56e5abcb432b, attempt 1, workflow_dispatch.

Timeline on 2026-10-01 (UTC):

• 01:53:41: run created.
• 01:58:22: application reports processing complete.
• 01:58:28: collection step logs The operation was canceled. and ends with conclusion cancelled.
• 01:58:50: every step is completed, including Complete job with success. The subsequent health step also succeeded.

At 05:39 UTC, the run page and authenticated REST run/job/check-run/attempt/list endpoints still showed status: in_progress, conclusion: null, and job completed_at: null. Run updated_at remained 2026-10-01T01:53:47Z.

Authenticated recovery requests, attempted once each:

• POST /repos/Shiba-0101/yukkuri-rankings/actions/runs/36803252795/cancel: HTTP 409.
• POST /repos/Shiba-0101/yukkuri-rankings/actions/runs/36803252795/force-cancel: HTTP 409 with exact response:

{"message":"Cannot cancel a workflow run that is not in progress.","documentation_url":"https://docs.github.com/rest/actions/workflow-runs#force-cancel-a-workflow-run","status":"409"}

The workflow has timeout-minutes: 15 and cancel-in-progress: false. A later scheduled run completed successfully at 03:18:11 UTC: https://github.com/Shiba-0101/yukkuri-rankings/actions/runs/36809587299 . It used a later commit, so this is not a same-commit reproduction.

We have not deleted the original run or altered its check result. The initial cancellation cause and the internal cause of the state inconsistency remain unknown. GitHub Status showed operational when checked. This inconsistent status prevents reliable operational checks. No credentials, database contents, or full logs are included.

[kurupdevs]

The fact that three separate repositories hit the exact same symptom within a couple of hours of each other is the strongest evidence in this thread. That timing makes a platform-side state glitch far more likely than anything in any of your workflows, and the fact that each of you could still trigger a fresh successful run backs that up. Since cancel, force-cancel, and delete have all been tried with authenticated requests and refused, the remaining route is GitHub Support, using the run IDs and job timelines already collected here as the evidence. Your workflows are not at fault and new runs are unaffected, so the stuck runs can safely be left in place while you wait for support.

[JimmyBlackley]

I hit the same issue on a self hosted runner on Azure, luckily I could ensure it wasn't keeping the vm alive..

https://github.com/medsplat/fact-batch/actions/runs/36801647450/job/110177562780 (non public, but happy to GH to investigate)