WARP_SIM_WEDGE_BACKSTOP

Wall-clock backstop for warpSimTest — the budget for a genuine wedge, not a performance assertion. Mirrors RAFT_SIM_WEDGE_BACKSTOP (:kuilt-raft-test) and TEST_WEDGE_BACKSTOP (:kuilt-test), which carry the same contract.

Why it is deliberately loose

A MultiNodeWarpSim test runs entirely on virtual time: StandardTestDispatcher, an in-memory InMemoryLoom mesh, and node clocks driven from TestScope.testScheduler. There is no real-clock input anywhere on the execution path, so the virtual trajectory — and therefore the total quantity of real work — is identical on every run. Machine load can change only the wall-clock rate at which that fixed work is retired.

A tight wall-clock cap over a fixed quantity of work is therefore not an assertion about the code at all. It asserts "this host can retire N units of work in T seconds". Measured on a 16-core box, an unchanged binary slowed 2.65× between load 7–10 and load 21–36, against 1.8× of headroom under the previous 5 s cap — degradation exceeding headroom, i.e. a deterministic red on a busy runner rather than a flake. Mutation-verified with the ceiling as the only variable: 5 s → 4/4 FAIL, 30 s → 4/4 PASS (kuilt #1891).

Do NOT tighten this back to a few seconds

The instinct is that a tight timeout buys fast failure. Here it does not — fast failure is already bought, load-independently, by the bounded await* helpers' within bound (2 s of virtual time, immune to contention), and those throw an AssertionError carrying a full MultiNodeWarpSim.dumpState. A tight outer cap fires before that can speak, producing a bare UncompletedCoroutinesError with no mesh state at all. Tightening it adds no detector; it pre-empts the legible ones with a load-sensitive false-red generator.

What it is for is the residual case the virtual bounds cannot cover: a wedge outside the bounded helpers — an unbounded await, a deadlocked hand-rolled Channel receive. 30 s still bounds that to half a minute.