slachiewicz opened a new pull request, #12679: URL: https://github.com/apache/maven/pull/12679
`MonotonicClockTest.testElapsedTimeConsistency` fails intermittently on CI, on PRs that have nothing to do with the clock (most recently on the Dependabot xmlunit bump, #12671): ``` [ERROR] org.apache.maven.api.MonotonicClockTest.testElapsedTimeConsistency org.opentest4j.AssertionFailedError: Elapsed time should match calculated duration between start and now ==> expected: <true> but was: <false> ``` ### Cause The test took two *separate* samples of the monotonic source and required them to agree within 1ms: ```java Instant now = clock.instant(); // nanoTime read #1 Duration elapsed = clock.elapsedTime(); // nanoTime read #2, taken later Duration calculated = Duration.between(clock.startInstant(), now); assertTrue(Math.abs(elapsed.toMillis() - calculated.toMillis()) <= 1, ...); ``` Normally the two reads are microseconds apart, so the 1ms budget holds. But a GC pause or a scheduler deschedule between them is enough to blow it on a loaded CI agent, and `toMillis()` truncation eats part of the budget as well. Nothing is wrong with `MonotonicClock` when this fires — the test is simply asserting a wall-clock timing bound. ### Fix Sandwich the `instant()` sample between two `elapsedTime()` samples and assert the ordering instead: ```java Duration before = clock.elapsedTime(); Instant now = clock.instant(); Duration after = clock.elapsedTime(); Duration calculated = Duration.between(clock.startInstant(), now); assertTrue(calculated.compareTo(before) >= 0 && calculated.compareTo(after) <= 0, ...); ``` All three values derive from the same `System.nanoTime()` base, so `before <= calculated <= after` holds no matter how long the JVM stalls between the calls. No tolerance and no timing assumption, and the assertion still catches a genuine inconsistency between `instant()` and `elapsedTime()` — which is what the test is there for. The failure message now prints all three durations. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
