timeoutDoesNotPoisonSubsequentInvokes

A timeout must not poison the runtime: the runaway op times out AGAIN on its next invocation (whatever the impl's recovery mechanism — a cleared interrupt, a re-armed deadline, a respawned worker — it must re-enforce the budget), and a well-behaved op on the SAME runtime still produces correct bytes afterwards.

Why the well-behaved arm asserts eventual success (#1739)

Both arms share one runtime and therefore one WasmSandboxConfig.executionTimeout. The runaway arm needs it tight (250 ms) or a non-conforming impl burns the test host; the well-behaved arm needs it generous, because reversing three bytes costs microseconds of guest work but its deadline also covers being scheduled onto a CPU. The well-behaved arm lost that argument twice on 2026-07-27, false-timing-out at 1-minute load averages of 41 and 71.6 and passing in isolation both times — a budget on the innocent op asserts "this host is not busy", not "the runtime recovered".

Since one config cannot be both tight and generous, the scenario is retried instead — and only on a budget overrun. Nothing this test protects is weakened, but the reason is not that a poisoned runtime reads differently: an unreset deadline is mapped to an overrun message by at least one impl. It is that (i) wrong bytes and a non-firing assertFailsWith never reach the retry (they are AssertionErrors, not WasmExecutionExceptions), (ii) a trap, an interrupt or a dead worker carries different message text, and (iii) any real recovery failure is persistent, so every attempt overruns and the bounded retry still fails. See retryingOnlyBudgetOverruns for the ordered argument and the one class it deliberately absorbs (#1802).

One runtime is reused across attempts deliberately: each extra attempt puts two more timeouts in front of the well-behaved invoke, which strengthens the recovery assertion, and a common-code suite cannot close a WasmRuntime to reclaim a discarded one.