awaitBudget

How long awaitRoster / awaitEvent / awaitFrame wait before failing with the state they observed — virtual time, null to wait unbounded.

Virtual, not wall-clock, is the whole point: this suite's harness runs on the test scheduler (newHarness takes the test's scope, and the partition tests drive advanceTimeBy + RoomHarness.advanceClock in lockstep), so the trajectory is identical on every run and a bound over it is deterministic. A wall-clock bound would assert "this host retires N units of work in T seconds", which is false exactly when the box is busy — the defect forbidTightRunTestTimeout exists to stop (#1739 / #1891).

Generous relative to this suite's own timescale rather than tight: fastHeartbeatConfig ticks every 100 ms and the longest deliberate advancement in the suite is ~1 s, so this leaves ~5× headroom. It is a wedge bound, not a latency assertion — nothing here asserts a fabric admits quickly, only that it admits. Expiry costs no wall-clock time worth measuring: the scheduler fast-forwards through the intervening virtual ticks.

Override to null if your harness does real I/O

A fabric whose delivery does not run on the test scheduler — a real socket, a real radio — does not advance the virtual clock, so runTest fast-forwards the entire budget while the frame is still on the wire and a working fabric fails. That is not hypothetical: it is kuilt #2069 / #2115, where a withTimeout(30.seconds) added to a SeamConformanceSuite obligation red-lit TcpConformanceTest on a 16 MiB frame that was crossing loopback fine. Such a harness sets this to null and takes runTest's own TEST_WEDGE_BACKSTOP ceiling as its backstop — losing the named failure, which is the honest trade for a real-I/O fabric.