1e4181b59e
Scenario#67.01 asserted the measured processor time in whole seconds, so it demanded a full core for a full second. On mih09, building at the same time, the busy loop gets a fraction of one — a correct measurement that truncates to zero, and it turned main red after PR#70. Milliseconds with a 300 ms threshold: still two orders of magnitude above what the waiting root shell itself costs, so the proof that the descent into the tree works is unchanged. PR#68 made the same correction to the sibling scenario and left this one behind. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: mhoennig <michael@hoennig.de> Reviewed-on: #71
42 lines
2.2 KiB
Markdown
42 lines
2.2 KiB
Markdown
> **WARNING:** This document describes only the change applied in this PR.
|
|
> It may already be outdated once the next PR is merged.
|
|
> Historic PR-documentation is not maintained along with new PRs — treat it as a snapshot, not as current documentation.
|
|
|
|
## Related Links
|
|
|
|
- [PR#67](2026-09-15-PR%2367-what-a-build-actually-cost.md) — introduced the test this PR corrects.
|
|
- [PR#68](2026-09-15-PR%2368-a-fifth-of-a-second.md) — corrected the same over-strict assertion in the sibling scenario.
|
|
|
|
## The Problem
|
|
|
|
`main` went red after PR#70 was merged, and with it the deployment: `Scenario#67.01` failed on mih09 while the branch build had been green.
|
|
|
|
The test burns processor time in a grandchild process for two seconds of wall clock and asserts that the tree's measured processor time is `greaterThan 0` — in *whole seconds*.
|
|
That assertion does not ask what the test is about.
|
|
It asks for a full core for a full second, which a busy loop gets on an idle laptop and does not get on a shared build host with three threads that is running a Gradle build at the same time.
|
|
Half a core for two seconds is a perfectly correct measurement of the thing being measured, and it truncates to zero seconds.
|
|
|
|
This is the same defect as `Scenario#67.03`, which PR#68 fixed by asserting milliseconds — the sibling scenario was left as it was, and it failed the next time the host was busy enough.
|
|
|
|
## Non-Goals
|
|
|
|
- Nothing about `ProcessTreeCpuTime` itself changes: the measurement was right, the assertion was wrong.
|
|
- No retry or tolerance mechanism for flaky tests in general.
|
|
|
|
## The Solution
|
|
|
|
The assertion moves to milliseconds with a threshold of 300 ms.
|
|
|
|
The threshold still carries the proof the test exists for.
|
|
The root shell of the tree waits and costs a few milliseconds of its own, so a reading two orders of magnitude above that can only come from the grandchild — which is what "the descent into the tree works" means.
|
|
What it no longer does is demand that the grandchild win a whole core on a machine that has other work to do.
|
|
The upper bound moves to milliseconds with it, unchanged in meaning.
|
|
|
|
## Additional Changes
|
|
|
|
- None.
|
|
|
|
## Prerequisite PRs
|
|
|
|
- [PR#70](2026-09-15-PR%2370-where-the-time-went.md) — merged just before this; its merge is what ran into the failure.
|