Filed unassigned by the dev seat working #7048, as an out-of-scope finding. #7048 fenced ceilings explicitly (⛔ Do not raise any job's timeout-minutes), and adding one where none exists is the same decision in the other direction — a change to what the gate rejects — so it was deliberately not taken there. Recording it rather than acting on it.
Attribution as prose: generated by Claude Code, dev session session_01BGMDbrVa8JjZcCQ7DWYH1b, while implementing #7048 (PR #7269).
The observation
Measured on main = adbda1bed by parsing all 31 workflow files (control: 31 files enumerated, 39 jobs parsed, non-zero):
| workflow |
job |
timeout-minutes |
required context? |
lint.yml |
lint |
⛔ none |
yes — pull_request and merge_group |
performance-budget.yml |
bundle-analysis |
⛔ none |
yes (#6245) |
changeset-release.yml |
release |
⛔ none |
no — publish/refresh lane |
ci.yml |
all 7 jobs |
10 / 15 / 20 / 20 / 20 / 30 / 40 |
yes |
live-e2e.yml |
live-e2e |
40 |
no — informational |
⇒ Every job in ci.yml and live-e2e.yml declares a ceiling. The three above do not, so theirs is GitHub's documented default of 360 minutes.
Why it may matter
This repository has been bitten twice by an unbounded operation whose only backstop was a job ceiling: the apt-get hang (#5304, three runs cancelled at 30 minutes each) and the cache-save stall (#6577, one all-green pull request ejected from the merge queue). In both, the ceiling converted a transient fault into a cancelled check — a gate that reports nothing — and the merge queue cannot tell cancelled from failure.
The two required contexts above would take that same fault at six hours instead of 20–30 minutes, on a shared serial queue.
⛔ What this does NOT claim
The actual decision for triage
Is an explicit ceiling on these three jobs worth adding — and if so, derived how? A ceiling set below a job's honest slowest run converts a working gate into a permanently red one, which is the mirror of the hazard #7048 fenced. Any number would need the same treatment #7048 gave its bounds: derived per job from that job's own measured distribution, not inherited from ci.yml's.
An alternative disposition that costs nothing: decide deliberately that 360 is accepted for these three and record that in the workflows, so the next reader knows the absence is a choice rather than an oversight.
Filed unassigned by the dev seat working #7048, as an out-of-scope finding. #7048 fenced ceilings explicitly (
⛔ Do not raise any job's timeout-minutes), and adding one where none exists is the same decision in the other direction — a change to what the gate rejects — so it was deliberately not taken there. Recording it rather than acting on it.Attribution as prose: generated by Claude Code, dev session
session_01BGMDbrVa8JjZcCQ7DWYH1b, while implementing #7048 (PR #7269).The observation
Measured on
main=adbda1bedby parsing all 31 workflow files (control: 31 files enumerated, 39 jobs parsed, non-zero):timeout-minuteslint.ymllintpull_requestandmerge_groupperformance-budget.ymlbundle-analysischangeset-release.ymlreleaseci.ymllive-e2e.ymllive-e2e⇒ Every job in
ci.ymlandlive-e2e.ymldeclares a ceiling. The three above do not, so theirs is GitHub's documented default of 360 minutes.Why it may matter
This repository has been bitten twice by an unbounded operation whose only backstop was a job ceiling: the
apt-gethang (#5304, three runs cancelled at 30 minutes each) and the cache-save stall (#6577, one all-green pull request ejected from the merge queue). In both, the ceiling converted a transient fault into acancelledcheck — a gate that reports nothing — and the merge queue cannot tellcancelledfromfailure.The two required contexts above would take that same fault at six hours instead of 20–30 minutes, on a shared serial queue.
⛔ What this does NOT claim
Lint5m14s,Bundle Analysis4m07s,release2m58s — nowhere near any ceiling.actions/cachesaves carry the unbounded-save exposure #6577 measured — across five workflows, not just ci.yml #7048's own fence says lifting or lowering a gate's ceiling changes the gate.The actual decision for triage
Is an explicit ceiling on these three jobs worth adding — and if so, derived how? A ceiling set below a job's honest slowest run converts a working gate into a permanently red one, which is the mirror of the hazard #7048 fenced. Any number would need the same treatment #7048 gave its bounds: derived per job from that job's own measured distribution, not inherited from
ci.yml's.An alternative disposition that costs nothing: decide deliberately that 360 is accepted for these three and record that in the workflows, so the next reader knows the absence is a choice rather than an oversight.