retryingOnlyBudgetOverruns

Runs scenario, retrying up to attempts times — but only when it fails by overrunning a runtime's wall-clock guest budget, and never on any other failure.

Why this exists (#1739)

WasmSandboxConfig.executionTimeout is a real wall-clock bound on real CPU-bound guest work. It cannot be driven by virtual time, so a test that exercises it is timing-gated by construction. That is correct for the runaway kernel the budget exists to catch. It is wrong for a well-behaved op that happens to share a runtime — and therefore the budget — with a runaway: reversing three bytes costs microseconds of guest work, but its deadline also covers being scheduled onto a CPU at all, and a saturated build host does not reliably manage that inside a few hundred milliseconds. Two of #1739's confirmed false reds were exactly this: an innocent invoke blowing a 250 ms / 200 ms budget at 1-minute load averages of 41, 52 and 71.6, and passing in isolation every time.

Raising the budget does not fix it. It buys a slower false red, and the runaway arm of the same test needs the budget tight so a non-conforming impl fails fast instead of burning the test host. Those two requirements are irreconcilable inside one WasmSandboxConfig — one runtime, one timeout — so the fix has to move to the assertion: the well-behaved arm asserts eventual success.

Why this does not weaken what the caller proves

Three independent filters, in the order they apply. Note that the type filter is the strongest and the message filter is narrower than it looks; the KDoc used to lead with a claim about trap text that is false for Wasm3WasmRuntime (its unreset-deadline trap is mapped to an overrun message, not a trap message), so the safety argument is stated here in dependency order instead.

1. Type. Only WasmExecutionException enters the catch at all. A AssertionError — a wrong-bytes assertContentEquals, an assertFailsWith that did not fire, anything assertAll re-raises — and a us.tractat.kuilt.warp.WasmLoadException both propagate untouched. That covers every corrupted-state and missing-failure outcome without inspecting a single string.

2. Message. Within WasmExecutionException, only BUDGET_OVERRUN_MARKER's full uniform phrasing is retried. A trap, an out-of-bounds ABI word, a rejected task on a dead worker and a stale JVM interrupt all read "<phase> trapped: …" or "WASM kernel failed: …".

3. Persistence. The filters above are not relied on to catch a runtime whose timeout no longer actually stops the guest, nor Wasm3WasmRuntime's unreset deadline — both of those do present as overruns. They are caught because they are persistent: the worker stays busy or the deadline stays armed, so every attempt overruns and attempts of them are not enough.

The one defect class this deliberately absorbs is #1802's transient residual-drain skew — a post-timeout op charged for the dying runaway's queue wait — whose deterministic guard ships with #1802's fix. Absent that, only the transient overrun of a contended host is absorbed.

The failure is self-describing

On exhaustion this reports every attempt's wall-clock duration and then times referenceInvoke — an equivalent well-behaved invocation on a fresh, generously-budgeted runtime — so the reader can separate contention from regression from the message alone, without re-running anything.

Two known gaps in that diagnostic, tracked by #1810: an absorbed overrun is silent (so drift from "no retry ever consumed" toward "three of four every run" is invisible until all four fail), and the reference price is one sample that includes load as well as the invoke it is compared against — both biases inflating it, i.e. nudging the reader toward the comfortable "blame the host" branch.

Parameters