Seen once on Build and Test (windows-latest, 22.x, 3.11) for a docs-only PR (#888, run 37990703352, 2026-10-09); the ubuntu job and the rerun passed.
FAIL unit tests/core/unit/session/session-manager-wait-for-stop.test.ts
> SessionManager - waitForStop (issue #849) > answers pending when its timeout passes with the program still running
AssertionError: expected { success: true, …(2) } to be undefined
Why it can fail. The file runs under vi.useFakeTimers({ shouldAdvanceTime: true }), so the fake clock also moves with real time (20 ms per real 20 ms by default). The case leaves itself a 1 ms margin:
const wait = track(sessionManager.waitForStop(sessionId, 2_000));
await vi.advanceTimersByTimeAsync(1_999);
expect(wait.result()).toBeUndefined(); // <- failed here
await vi.advanceTimersByTimeAsync(1);
Between creating the wait and the first assertion, any real time that advanceTimersByTimeAsync and the awaited microtasks take is added to the fake clock on top of the 1,999 ms. On a slow runner that is more than 1 ms, the 2 s timeout fires inside the advance, and the wait has already answered pending: true when the test expects it still open. The assertion is right about the behaviour and wrong about the clock.
Fix shape (test only). Keep the margin out of real time's reach: assert "still open" at 1,000 ms (or 1,900), then advance the rest. Or run this one case with shouldAdvanceTime off, since nothing in it needs real-time progression. Either keeps the case's point (the answer comes exactly at the timeout, and says what is armed).
Seen once on
Build and Test (windows-latest, 22.x, 3.11)for a docs-only PR (#888, run 37990703352, 2026-10-09); the ubuntu job and the rerun passed.Why it can fail. The file runs under
vi.useFakeTimers({ shouldAdvanceTime: true }), so the fake clock also moves with real time (20 ms per real 20 ms by default). The case leaves itself a 1 ms margin:Between creating the wait and the first assertion, any real time that
advanceTimersByTimeAsyncand the awaited microtasks take is added to the fake clock on top of the 1,999 ms. On a slow runner that is more than 1 ms, the 2 s timeout fires inside the advance, and the wait has already answeredpending: truewhen the test expects it still open. The assertion is right about the behaviour and wrong about the clock.Fix shape (test only). Keep the margin out of real time's reach: assert "still open" at 1,000 ms (or 1,900), then advance the rest. Or run this one case with
shouldAdvanceTimeoff, since nothing in it needs real-time progression. Either keeps the case's point (the answer comes exactly at the timeout, and says what is armed).