What is wrong
Workflow run 32219727413 has been queued since 2026-08-19, with updated_at equal to created_at and zero jobs — it never expanded. It is not a job waiting for a runner. It is a corrupted run, and no API call can reach it.
It was orphaned by fc1d29b, which retired the MkDocs workflow at .github/workflows/docs.yml and made ReadTheDocs the only documentation builder. That was the right change; the run had already been queued when the definition went away.
Everything that has been tried, and what each answers
Measured 2026-09-10, with the workflow in both states:
|
workflow deleted |
workflow active |
gh run cancel |
"Cannot cancel a workflow run that is completed" |
same |
POST /cancel |
409 "has not been queued yet" |
409 "has not been queued yet" |
POST /force-cancel |
409 "has not been queued yet" |
409 "has not been queued yet" |
DELETE /runs/{id} |
403 "Could not delete the workflow run" |
403 same |
POST /rerun |
— |
403 "This workflow is already running" |
The answers contradict each other and contradict the run's own record. GET /runs/32219727413 returns status: queued; /cancel says it was never queued; /rerun says it is running now. Deletion needs a completed run, and it cannot be completed.
The placeholder approach does not work — twice now
The theory was that the run is unreachable because its workflow reports state: deleted, so restoring .github/workflows/docs.yml would return it to active and let the cancel through.
It does return the workflow to active. It does not release the run. Verified today in 651871c (restore) and 97baa5e (revert), with all four endpoints retried in between.
This is the second attempt. f2d12d7 did the same on 2026-08-20 and 44281e6 reverted it the next day. That earlier revert was correct — the placeholder ran green as 32341656072 and the orphan stayed queued regardless. What was missing was the evidence, which is why it got tried again. A fresh dispatch today (34438521413) also completed successfully, confirming the workflow definition is fine and the fault is specific to this one run.
Do not try the placeholder a third time.
What is left
GitHub Support. A run in an internally inconsistent state is theirs to clear; there is no repository-side action that reaches it. Worth quoting the three contradictory responses above in the ticket, since they demonstrate the inconsistency rather than merely asserting it.
What it costs while it sits there
It reads as a permanently active run, so it shows up in every workspace sweep:
workflow_attention.sh lists it on every run.workflow_watch.sh used to hang on it — that script waited until no run was active, and this one never completes. Fixed in the workspace anchor (be5d735): a run active longer than --stuck-after is now reported WEDGED and no longer waited on, and --timeout bounds the script regardless.
So the tooling no longer breaks on it, but it will keep appearing in reports until GitHub clears it.
What is wrong
Workflow run 32219727413 has been
queuedsince 2026-08-19, withupdated_atequal tocreated_atand zero jobs — it never expanded. It is not a job waiting for a runner. It is a corrupted run, and no API call can reach it.It was orphaned by
fc1d29b, which retired the MkDocs workflow at.github/workflows/docs.ymland made ReadTheDocs the only documentation builder. That was the right change; the run had already been queued when the definition went away.Everything that has been tried, and what each answers
Measured 2026-09-10, with the workflow in both states:
deletedactivegh run cancelPOST /cancelPOST /force-cancelDELETE /runs/{id}POST /rerunThe answers contradict each other and contradict the run's own record.
GET /runs/32219727413returnsstatus: queued;/cancelsays it was never queued;/rerunsays it is running now. Deletion needs a completed run, and it cannot be completed.The placeholder approach does not work — twice now
The theory was that the run is unreachable because its workflow reports
state: deleted, so restoring.github/workflows/docs.ymlwould return it toactiveand let the cancel through.It does return the workflow to
active. It does not release the run. Verified today in651871c(restore) and97baa5e(revert), with all four endpoints retried in between.This is the second attempt.
f2d12d7did the same on 2026-08-20 and44281e6reverted it the next day. That earlier revert was correct — the placeholder ran green as32341656072and the orphan stayed queued regardless. What was missing was the evidence, which is why it got tried again. A fresh dispatch today (34438521413) also completed successfully, confirming the workflow definition is fine and the fault is specific to this one run.Do not try the placeholder a third time.
What is left
GitHub Support. A run in an internally inconsistent state is theirs to clear; there is no repository-side action that reaches it. Worth quoting the three contradictory responses above in the ticket, since they demonstrate the inconsistency rather than merely asserting it.
What it costs while it sits there
It reads as a permanently active run, so it shows up in every workspace sweep:
workflow_attention.shlists it on every run.workflow_watch.shused to hang on it — that script waited until no run was active, and this one never completes. Fixed in the workspace anchor (be5d735): a run active longer than--stuck-afteris now reported WEDGED and no longer waited on, and--timeoutbounds the script regardless.So the tooling no longer breaks on it, but it will keep appearing in reports until GitHub clears it.