[ML] Make CMonotonicTimeTest robust to sleep overshoot on CI

[edsavage]

Summary

CMonotonicTimeTest::testMilliseconds / testNanoseconds slept for one second and asserted the monotonic timer advanced by a value inside a fixed [900, 1200]ms window. That effectively tested std::this_thread::sleep_for accuracy rather than the timer itself. On oversubscribed CI machines (notably the macOS aarch64 Orka VMs) the sleep can overshoot well past the 1200ms upper bound, causing intermittent failures.

An example failure: ml-cpp-snapshot-builds #7092 (test_macos-aarch64-RelWithDebInfo, branch 9.5):

During 1 second the monotonic millisecond timer advanced by 1293 milliseconds
*** 1 failure is detected in the test module "Master Test Suite"

The timer was behaving correctly; it faithfully reported the ~1293ms that actually elapsed while the thread was descheduled.

Fix

The tests still sleep for a nominal one second, but replace the fragile fixed [900, 1200]ms window with two complementary checks:

1. Cross-domain lower bound (diff > 900ms / 900000000ns): sleep_for guarantees it sleeps for at least the requested duration, so a reading well below one second means the monotonic clock is running too slowly or has stalled. This is the only genuinely independent check that the clock ticks at roughly real-time rate, because it compares against a different clock domain (the scheduler's sleep timer). A 10% margin absorbs coarse-timer granularity and cross-clock skew.

2. Cross-clock consistency check (agreement with std::chrono::steady_clock over the same interval, within 5%): validates CMonotonicTime's own unit-scaling arithmetic. This bounds diff from above, but only against the actual elapsed time measured over the same window.

There is deliberately no upper bound relative to the nominal sleep duration. sleep_for only promises a minimum sleep and can overshoot arbitrarily on loaded/oversubscribed hosts - that's a scheduler property, not a timer defect - which is exactly what made the old diff < 1200 assertion flaky. The rationale is documented in a block comment in the test.

Test plan

• Built ml_test_core locally (macOS aarch64, RelWithDebInfo).
• Ran CMonotonicTimeTest: both cases pass; the two clocks agree to <1ms (ms case) and <1us (ns case).
• Compiled the test with -Wall -Wextra: zero warnings (fixed a latent -Wsign-compare).

[elasticsearchmachine]

Pinging @elastic/ml-core (Team:ML)

[Copilot]

Copilot review overview

🟡 Changes recommended

Address the remaining timing assertions, measurement skew, documentation, and formatting issues.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1

Open (2)

• Millisecond test still enforces an unintended 900 ms floor · New
• Avoid claiming identical hardware counters across all platforms · New

What changed in this PR

Updates CMonotonicTimeTest to tolerate sleep overshoot by comparing elapsed time with steady_clock.

Changes:

• Adds millisecond and nanosecond reference-clock measurements.
• Uses a 5% agreement tolerance.
• Updates test rationale and diagnostics.

File	Summary
lib/​core/​unittest/​CMonotonicTimeTest.cc	Updates monotonic timer tests, assertions, and logging.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[elastic-vault-github-plugin-prod]

💚 All backports created successfully

Status	Branch	Result
✅	9.4
✅	9.5
✅	8.19

Questions ?

Please refer to the Backport tool documentation and see the Github Action logs for details