The four-tier timeout section added in #688 records this as a gap rather than a decision, and this issue holds the measurements a later pass needs.
What is missing
.config/nextest.toml sets no global-timeout. This repository runs nextest, so the budget exists to be set and has not been.
Until it is, the cargo watchdog is doing tier two's job as well as its own. A run whose tests each stay inside their allowance can still exceed the watchdog between them, and the failure then names cargo rather than the run.
The values a later pass needs
| Quantity |
Value |
Source |
| Largest per-test allowance |
600 s |
60s period times terminate-after = 10, the Windows override |
| Cargo watchdog |
1,800 s |
RUN_RUST_CARGO_WAIT_TIMEOUT at job level in both coverage workflows |
| Worst coverage step |
669 s |
run 34047430187, ci.yml build-test |
| Worst coverage step, trunk |
624 s |
run 33809357448, coverage-main.yml |
| Job ceiling |
60 m |
both coverage jobs |
Read across twelve successful runs of each workflow. None was a genuinely cold compile.
The constraints a value has to satisfy
global-timeout > largest per-test allowance (600 s)
watchdog >= global-timeout + termination + cold build
The termination allowance is read from the largest configured slow-timeout.grace-period with a 60 s floor; this file sets none, so the floor applies. With a 1,800 s watchdog that leaves at most 1,740 s minus the cold build for the whole-run budget, so a value between 600 s and roughly 20 minutes fits without moving the watchdog. A larger budget needs the watchdog raised with it.
What is already in place
tests/workflow_contracts/timeout_ordering_test.py binds the value the moment one appears: above the largest per-test allowance, and inside the watchdog once termination and a cold build are counted. It skips today and says why, so adding the budget lands in the right place rather than merely somewhere.
Note that the per-test allowance is period multiplied by terminate-after, not the period alone. Every period here is 60 s, so reading the period would understate the largest allowance tenfold.
Canonical wording
leynos/shared-actions' generate-coverage README, section "Sizing the budget against the timers around it".
The four-tier timeout section added in #688 records this as a gap rather than a decision, and this issue holds the measurements a later pass needs.
What is missing
.config/nextest.tomlsets noglobal-timeout. This repository runs nextest, so the budget exists to be set and has not been.Until it is, the cargo watchdog is doing tier two's job as well as its own. A run whose tests each stay inside their allowance can still exceed the watchdog between them, and the failure then names
cargorather than the run.The values a later pass needs
60speriod timesterminate-after = 10, the Windows overrideRUN_RUST_CARGO_WAIT_TIMEOUTat job level in both coverage workflowsci.ymlbuild-testcoverage-main.ymlRead across twelve successful runs of each workflow. None was a genuinely cold compile.
The constraints a value has to satisfy
The termination allowance is read from the largest configured
slow-timeout.grace-periodwith a 60 s floor; this file sets none, so the floor applies. With a 1,800 s watchdog that leaves at most 1,740 s minus the cold build for the whole-run budget, so a value between 600 s and roughly 20 minutes fits without moving the watchdog. A larger budget needs the watchdog raised with it.What is already in place
tests/workflow_contracts/timeout_ordering_test.pybinds the value the moment one appears: above the largest per-test allowance, and inside the watchdog once termination and a cold build are counted. It skips today and says why, so adding the budget lands in the right place rather than merely somewhere.Note that the per-test allowance is
periodmultiplied byterminate-after, not the period alone. Every period here is 60 s, so reading the period would understate the largest allowance tenfold.Canonical wording
leynos/shared-actions'generate-coverageREADME, section "Sizing the budget against the timers around it".