Fix FuturesTest's wall-clock timing assumptions - #295

FuturesTest asserts on wall-clock time in ways that break on shared runners. testBrokenSleep is already failing on macOS; the other two changes here are the same problem caught before it lands.

testBrokenSleep

The test slept a nominal 500 ms across four awaits and required the total to land in [500, 1000]. On the macOS runners it came in at 1001 ms and 1008 ms, failing by 1 ms and 8 ms. It has been failing since at least 2026-07-22, on main as well as on pull requests.

The overhead is structural rather than contention. Each awaited Rust timer spawns a thread and resumes back through the FFI, which costs about 5 ms locally and roughly 125 ms per await on a shared macOS runner. testSleepWithRepeat shows the same effect independently in the same job: 65 sequential 20 ms sleeps, nominal 1.3 s, actual 6.9 s. Raising the cap only moves the cliff, since that cost has no upper bound on a shared VM.

What the test is for is that a waker firing a second time does not corrupt its own future or let a later one finish early. That is a lower bound, and lower bounds do not care how loaded the machine is: thread::sleep is an at-least guarantee and measureTime is monotonic. So each step now asserts it took at least as long as it slept, and the upper bound is gone. A future that never completes is still caught by runTest's own timeout.

These bounds are weaker than ones the file already relies on. assertApproximateTime asserts an exact nominal lower bound with no slack on eight other tests, across these same platforms.

testFutureWithLockButNotCancelled

Next in line to flake: nominal 100 ms, window [100, 600], and CI was already spending 488 ms of it. The upper bound was never the detector. use_shared_resource returns Result<(), AsyncError> and throws AsyncError.Timeout against its own 1000 ms budget if the resource is not released, so the exception is what catches a real fault. Same treatment: keep the lower bound, drop the window.

testFutureWithLockAndCancelled

A different problem in the same file. The test launches a job, waits for it to take the lock, then cancels it. That wait was a plain delay(50) inside runTest, which runs on the virtual clock and returns in about 3 ms, measured. The job was being cancelled before it ever took the lock, so the test had not been exercising the case it describes. Moving the wait onto Dispatchers.Default makes it real, which took the test from 1-15 ms to 68 ms.

Its wall-clock cap is removed rather than widened, for the same reason as its sibling: an unreleased lock surfaces as AsyncError.Timeout from the second acquire, and any cap large enough to be safe today is still a cliff on a runner that spent 388 ms of overhead on a single call in this very file.

Testing

All three pass locally on jvmTest and macosArm64Test, and uniffi-tests-gir, macos passes on CI. Each was also checked in the failing direction: shortening a sleep to simulate a future completing early trips the new lower bound, and releasing the shared resource immediately trips the other one. The old testBrokenSleep measured 523 ms locally unloaded and 524 ms under 96 spinners on 12 cores, which is why this reproduces on CI runners and not on a laptop.

What this gives up

A future that completes late but eventually, say after five seconds, is now caught by runTest's 60 s timeout rather than by a 1000 ms cap. That trade is deliberate.

Written with AI assistance (Claude Code) and pending human review, per CONTRIBUTING.md.

🤖 Generated with Claude Code