Skip to content

CONCEPT Cited by 1 source

Abort recovery

Definition

Abort recovery is the runtime discipline of detecting a non-unwindable failure — an abort — and reinitialising the sandbox from known-good state so that future operations can succeed. Distinct from concepts/panic-unwind, which unwinds a recoverable failure without losing state.

The canonical wiki instance is Wasm-instance abort recovery as implemented in Cloudflare's 2026-04 wasm-bindgen work.

The class of failure abort recovery addresses

Even when concepts/panic-unwind is enabled, non-unwindable aborts still happen. Most common cause: out-of-memory. By definition, an abort cannot unwind — there is no chance to preserve state. The runtime's only option is to reinitialise. Quoting the source:

"While aborts are never ideal, and reinitialization on failure is an absolute worst-case scenario, implementing critical error recovery as the last line of defense ensures execution correctness and that future operations will be able to succeed. The invalid state does not persist, ensuring a single failure does not cascade into multiple failures."

Distinguishing abort from unwind: Exception.Tag

Once a Wasm module can both unwind (for panics) and abort (for OOM etc.), the embedder receives both shapes through the same Wasm Exception Handling machinery. The JS-side code needs to tell them apart. Cloudflare's design choice was to "mark all errors which are definitely unwinds" rather than mark aborts:

"We had two options to solve this technically: either mark all errors which are definitely aborts, or mark all errors which are definitely unwinds. Either could have worked but we chose the latter. Since our foreign exception handling was directly using raw WAT-level (WebAssembly text format) Exception Handling instructions already, we found it easier to implement exception tags for foreign exceptions to distinguish them from aborting non-unwind-safe exceptions."

An unknown/unmarked exception shape therefore must be treated as an abort — the conservative default.

set_on_abort hook

wasm-bindgen exposes set_on_abort at initialisation time so the embedder (workers-rs, a library consumer, …) can attach a handler that "recovers accordingly for the platform embedding's needs." The abort hook is where patterns/reinitialize-on-unrecoverable-error actually lives.

Reentrancy guards

Wasm allows deeply interleaved call stacks — Wasm calls into JS which calls back into Wasm at arbitrary depths, and multiple tasks can be executing in the same instance concurrently. An abort occurring in one task or deep stack frame must also invalidate any higher stacks reachable through JS, or the runtime ends up with undefined behaviour in formally-live stack frames built on invalidated instance state. Cloudflare calls these abort reentrancy guards: "Care was required to ensure we can guarantee the execution model, and contribution in this space remains ongoing."

Experimental: abort recovery for JS-imported libraries

wasm-bindgen's --reset-state-function (experimental) exposes a function on the generated bindings that lets the Rust application request its Wasm instance be reset to initial state for the next call, without the JS consumer reimporting or recreating the bindings. Orphaned class instances from the old instance throw on use; new class constructions work. This broadens abort recovery beyond Rust Workers to any JS app embedding a wasm-bindgen library — "the JS application using a Wasm library is errored but not bricked."

Seen in

Last updated · 510 distilled / 1,221 read