RAFT_SIM_WEDGE_BACKSTOP

Wall-clock backstop for raftSimTest — the budget for a genuine wedge, not a performance assertion.

Why it is deliberately loose

A MultiNodeRaftSim test runs entirely on virtual time: StandardTestDispatcher, per-node seeded Random, an in-memory MultiNodeRaftNetwork, and RaftConfig.expectVirtualTime. 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, the heaviest current raftSimTest costs 0.435 s near-idle and 1.453 s under a routine multi-agent build load — 3.34×, with a sibling test degrading 3.47× (uniform CPU contention, not a hot loop). Against the previous 5 s cap that left ~3× of margin, which a full ./gradlew build --rerun-tasks closes; the result was recurring false reds across three unrelated modules (kuilt #1382).

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 (DEFAULT_AWAIT, 2 s of virtual time, immune to contention) and by the MAX_ELECTION_THRASH churn bound. Both fail fast and emit a full MultiNodeRaftSim.dumpState. A tight outer cap fires before either can speak, producing a bare UncompletedCoroutinesError with no cluster 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, and dumpOnWedge makes it legible when it fires.