[CI] ubuntu-latest jobs canceled before runner assignment

[dalexsoto]

Failure signature

GitHub Actions jobs targeting ubuntu-latest remain unassigned for approximately 75-86 minutes and then end as canceled. For every occurrence, the job metadata reports runner_id: 0, an empty runner name, and zero executed steps.

Stable signature: github-actions-ubuntu-latest-unassigned-runner-canceled
Classification: CI infrastructure failure
Recurrence: 2 distinct PRs, 4 confirmed occurrences
First observed: 2026-08-06 17:31:57 UTC
Latest observed: 2026-08-06 19:06:12 UTC

Confirmed occurrences

PR / head	Workflow / job	Run / job	Observed interval
#26418 / 8c12572c897e1c6e25cb94f8e93fbed1c6fd074c	Autoformat code v2 / Autoformat and push	run 31123395950, job 92688718765	17:31:57-18:47:47 UTC
#26418 / 8c12572c897e1c6e25cb94f8e93fbed1c6fd074c	PR yamllint check / yamllint check	run 31123395914, job 92688718660	17:31:57-18:50:38 UTC
#26418 / 8c12572c897e1c6e25cb94f8e93fbed1c6fd074c	zizmor / zizmor	run 31123396010, job 92688718832	17:31:57-18:57:50 UTC
#26408 / cde4ac8065b5ff26886d9575036ff76bfbc8eb3c	zizmor / zizmor	run 31124297839, job 92691589511	17:50:35-19:06:12 UTC

Impact

The affected PR checks remain canceled/failing even though no workflow step or repository code executed. This can block otherwise healthy PRs from becoming merge-ready.

Investigation

• All four jobs target ubuntu-latest.
• All report runner_id: 0, an empty runner name, and no steps.
• Autoformat, yamllint, and zizmor contain no workflow concurrency rule that explains these cancellations.
• The cancellation initiator is not exposed in retained job metadata.
• Azure DevOps validation for the affected PRs continued without the same symptom.
• Separate searches across open and closed dotnet/macios issues for the stable signature, no-runner cancellations, workflow names, and ubuntu-latest found no matching issue.

Retry and workaround

No retry was submitted by the CI monitor: its retry policy authorizes Azure DevOps retries, not GitHub Actions reruns. There is no confirmed repository-side workaround; recovery requires GitHub-hosted runner capacity or a repository owner rerunning the affected workflow after capacity recovers.

GitHub run and job metadata are retention-limited. No step logs exist because the jobs never received a runner.