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
2.2 KiB
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 — introduced the test this PR corrects.
- PR#68 — 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
ProcessTreeCpuTimeitself 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 — merged just before this; its merge is what ran into the failure.