Actions steps completed but run stays in_progress; cancel refused and replacements queued

[dudden29]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Other

Discussion Details

On 11 November 2026 (UTC), I observed conflicting GitHub Actions states in a private repository.

Observed behavior

• A pull-request workflow started around 20:16 UTC. Every step in an inspected job, including cleanup and Complete job, was reported completed successfully by about 20:18 UTC.
• The workflow and job continued to report in_progress, with a null conclusion. The web UI also showed In progress.
• Clicking Cancel workflow returned: "Cannot cancel a workflow run that is not in progress."
• A request to rerun the job had previously been refused because the containing workflow was already running.
• One empty commit (unchanged source tree) triggered replacement checks around 20:32 UTC. Those checks remained queued on subsequent API and UI checks. I have stopped creating further retries.

Expected behavior

Finished jobs should reach a terminal state, and the UI/API should agree about whether a run can be cancelled or rerun. Replacement checks should either start or show an actionable reason for waiting.

I searched for similar discussions and found reports about queued runs and cancellation conflicts, including #212468. This report adds the case where all inspected job steps have finished but the parent state remains in_progress. I have not established whether runner capacity or another backend condition is responsible.

Could GitHub staff advise whether these states need backend reconciliation and how to resume checks safely? What private channel can be used to provide affected run IDs if needed? Repository names, run links, code, logs, and account billing details are intentionally omitted from this public report.

[aungzayyanaing]

Your symptoms line up with the platform incident GitHub reported that evening, not with anything in your workflow.

GitHub posted at 20:48 UTC on 11 November 2026 that Actions was experiencing degraded availability (Pages, Copilot, and Webhooks were also affected), and at 21:21 UTC that the backlog of Actions jobs had been fully processed and the incident was resolved: https://www.githubstatus.com/incidents/dvy0t3mvh1lg

A run whose steps had all completed by 20:18 UTC, whose parent run stayed in_progress with a null conclusion, whose cancel request was refused as "not in progress", and whose replacement checks stayed queued, is exactly the kind of backend state inconsistency a job backlog produces: the job steps are recorded as complete, but the parent run's terminal state was never written, so the UI and API disagree about whether it can be cancelled or re-run.

There is no user-side way to force that state closed. No UI button, gh command, or REST endpoint can move a run to a terminal state when GitHub's backend still holds it as in progress; cancel and re-run are both gated on that recorded status, which is why yours were refused.

What to do now:

• Check that run again now that the incident is resolved. Most runs caught in the backlog were finalized when it was processed.
• If it is still in_progress, stop creating replacement runs for it — they will keep queueing behind the stale run.
• Open a ticket with GitHub Support (support.github.com) and include the run and job IDs, the run URL, the timestamps, and the API output showing in_progress with a null conclusion and the cancel error. That is the private channel for this: only GitHub Support can reconcile the backend state for a private repository, and run IDs and logs should not be posted here.
• Once the stale run is terminal, or Support confirms it has been cleared, trigger a fresh run for the latest commit. Do not rely on the checks that were queued during the incident.