Linear memory growth limits and host-call atomicity

Direct Answer

There is no standardized WebAssembly mechanism to roll back host-import side effects after a memory.grow trap. The core specification defines memory.grow as atomic with respect to the module's own linear memory, but it establishes no transactional boundary around imported host calls. If an import modifies external state and a subsequent memory.grow fails, those modifications persist. The host runtime must implement its own consistency strategy.

Confirmed Facts vs. Likely Explanations

Confirmed: In WebAssembly 1.0 (and the current core 2.0 draft), memory.grow either succeeds and updates the memory size or fails without changing memory. For 32-bit memories, the practical ceiling is typically 4 GiB unless the memory64 proposal is enabled. The specification does not define rollback semantics for host imports.

Likely but implementation-dependent: Some host runtimes may buffer external writes or expose checkpoint APIs, but these are not mandated by the core spec. Assuming silent rollback or automatic retry safety without host cooperation is unsafe.

Steps for This Case

1. Design imports for idempotency. If a host function can be safely retried without duplicating effects, a trap after partial execution is recoverable.
2. Use a two-phase pattern. Split stateful imports into a "prepare" phase that validates capacity and a "commit" phase that applies changes only after memory growth is known to succeed.
3. Snapshot external state. Before invoking a sequence of imports that may be followed by memory.grow, record mutable external state. On trap, revert to the snapshot or mark the operation incomplete.
4. Fail fast. Check available memory headroom in the host before calling imports that will require growth, avoiding the trap entirely when possible.

Verification

Build a test module that calls a stateful import, then attempts memory.grow beyond the maximum. After the trap, inspect whether the import's external write persists. This confirms that your runtime does not silently roll back host state.

Missing Diagnostic

Does your host runtime expose a checkpoint, rollback, or transaction API for the imported functions that modify external state? If yes, the recommendation shifts toward runtime-managed snapshots; if no, the module and host must coordinate idempotency manually.