You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test (macos-latest) is cancelled after ~15 minutes without ever acquiring a runner #890
test (macos-latest) is cancelled after ~15 minutes without ever acquiring a runner
Blocking #889, which is a README + one test file and touches no workflow.
What happens
Three attempts on the same commit, each started by gh run rerun --failed:
attempt
started (UTC)
completed
duration
runner
steps
1
15:40:15
15:56:43
16m28s
""
0
2
16:44:14
16:59:15
15m01s
""
0
3
17:00:26
17:15:27
15m01s
""
0
Every one ends conclusion: cancelled with zero steps and an empty log:
the job never started. While queued the API reports "runner": null; after
cancellation, "runner": "".
gh pr checks renders this as fail, which is what makes it expensive — it
reads as a test failure on a pull request that changes no code, and the first
instinct is to go looking for a broken test that never ran.
It is not the workflow, the label or the plan
A control, same job name, same workflow, same day — run 41845361857 on main,
14:13 UTC:
It acquired a runner and ran for 49 minutes — well past the ~15 minutes
that kills the queued ones. So macos-latest resolves, the account can obtain
macOS runners, and a job that gets one completes normally.
Ruled out in .github/workflows/ci.yml:
no concurrency: block, so nothing in this repository cancels an in-flight
run when another starts;
no timeout-minutes: on any job (8 runs-on: entries, zero timeout-minutes:).
Why this is filed rather than retried again
Attempts 2 and 3 were cancelled at 15m01s each, to the second. Identical
durations are not the signature of a busy pool; they are the signature of a
fixed cap being reached. Retrying a reproducible cutoff a fourth time would be
treating a deterministic outcome as an intermittent one.
What would close it
Find what imposes the ~15 minute acquisition limit — an org or account runner
policy, a macOS concurrency ceiling, or a cancellation from outside this
repository — and either raise it or make the lane report "no runner" distinctly
from "the tests failed". The second half matters on its own: a check that
cannot say nothing ran costs a reader the same attention as a real failure,
every time.
Not attributed here: ~25 sessions share this account, and naming one as the
canceller without a control would be a guess.
Activity