Skip to content

PATTERN Cited by 1 source

Reinitialize on unrecoverable error

Intent

When a sandbox or runtime reaches a state that cannot safely be used for the next operation — and the failure mode can't be unwound — discard the invalidated state and spin up a fresh instance from initial state. The goal is not to preserve any in-flight work; it is to stop the failure from cascading to future operations.

When to use

  • The failure mode is non-recoverable — stack unwinding isn't possible or isn't safe (e.g. out-of-memory, corrupted linear memory, deeply interleaved invariant violation).
  • The sandbox is long-lived and serves many subsequent operations — so containing the failure matters even though the current one is lost.
  • You have a cheap way to construct a fresh instance (milliseconds for a Wasm module, seconds for a container, etc.).

The canonical wiki instance is Wasm-instance reinitialisation on a Cloudflare Worker after a Rust abort: the set_on_abort hook fires, the wasm-bindgen JS glue discards the invalidated Wasm instance, a new one is constructed, and subsequent requests run on the fresh state. See concepts/abort-recovery.

Relationship to concepts/panic-unwind

This pattern is the fallback, not the first choice:

  • If the failure can unwind — prefer concepts/panic-unwind. Destructors run, locks release, the instance remains valid, in-memory state is preserved, and only the failing request is lost.
  • If the failure cannot unwind — reinitialise. State is lost but the service continues.

The two compose in a typical Wasm sandbox: panics unwind and preserve state (the common case); genuine aborts reinitialise (the rare, worst case).

Cloudflare's two-generation use

  • workers-rs 0.6 — JS-side Proxy- based encapsulation detects Rust panics at the Rust↔JS boundary and triggers reinitialisation via targeted patches to wasm-bindgen's generated bindings. Platform-side only.
  • workers-rs 0.8 — upstreamed into wasm-bindgen proper via the set_on_abort hook. The embedder registers a handler at init time that handles the abort path. The same shape is available to every wasm-bindgen consumer, not just workers-rs.

A sibling extension — --reset-state-function (experimental) — exposes the reinit primitive to JS consumers of wasm-bindgen libraries. Class instances from the old Wasm instance throw (handles orphaned); new constructors work. "The JS application using a Wasm library is errored but not bricked."

Strengths

  • Bounds cascading failure. The invalid state does not persist; one failed request does not keep poisoning subsequent traffic.
  • Cheap for Wasm. A fresh Wasm instance starts in milliseconds on modern engines — the reinit tax is bounded.
  • Simple semantics. "The sandbox is broken; drop it and make a new one." Embedders can reason about the state-machine boundary without tracking partial recovery.

Weaknesses

  • Worst-case outcome for stateful workloads. If the sandbox held meaningful in-memory state shared across requests (a Durable Object is the named example in the source), that state is lost on reinit. Any in-flight requests other than the failing one are also collateral damage.
  • Not a substitute for actual fix. If aborts happen often — e.g. repeated OOM at a known workload pattern — reinitialisation is masking a resource-sizing bug, not addressing it.
  • Reentrancy edge cases are real. When Wasm↔JS↔Wasm call stacks are deeply interleaved, invalidating one invalid-instance frame must also invalidate higher stacks that implicitly depended on its state — or undefined behaviour remains. Cloudflare notes this explicitly: "Care was required to ensure we can guarantee the execution model, and contribution in this space remains ongoing."

Seen in

Last updated · 510 distilled / 1,221 read