fix(execution): size the wasm runner V8 heap so warmup stops OOMing

[NathanFlurry]

Problem

WASM command warmup fails with the opaque ERR_AGENTOS_NODE_SYNC_RPC: WebAssembly warmup exited with status 1 (Error: null). Root cause:

• The wasm runner isolate is started with JavascriptExecutionLimits::default() (crates/execution/src/wasm.rs), so its V8 heap falls back to isolate::DEFAULT_HEAP_LIMIT_MB = 128 MiB — the per-guest-isolate budget (mirrors Cloudflare Workers).
• But the runner is trusted infrastructure that must compile the WASI runtime + the guest's wasm module (e.g. bash.wasm) into its own heap before the guest runs. That routinely exceeds 128 MiB.
• The near_heap_limit_callback then terminates the isolate with an uncatchable, message-less exception → warmup dies → surfaces as status 1 (Error: null). Sidecar log shows warn "bounded limit exhausted" limit=v8_heap_bytes observed=131072000 capacity=131072000 fill_percent=100. A clean release hits this too.

Fix

Size the runner heap explicitly — default 2048 MiB, operator-tunable via AGENTOS_WASM_RUNNER_HEAP_LIMIT_MB — instead of leaving it on the per-guest default:

limits: JavascriptExecutionLimits {
    v8_heap_limit_mb: Some(wasm_runner_heap_limit_mb(request)),
    ..JavascriptExecutionLimits::default()
},

This does not weaken guest isolation. The guest module's memory/fuel/stack stay bounded separately, Rust-side, from request.limits (AGENTOS_WASM_MAX_MEMORY_BYTES etc.). The value is a V8 heap ceiling (heap_limits(0, cap)), committed only as used.

Test

wasm_runner_heap_limit_defaults_and_honors_operator_override covers the bounded default (asserts > 128), a positive operator override, and zero/non-numeric fallback to default. (A live OOM-repro needs a >128 MiB module + wasm artifacts, so it's not a deterministic unit test; the resolver + call-site change are covered.)

[railway-app]

🚅 Deployed to the secure-exec-pr-129 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
secure-exec	😴 Sleeping (View Logs)		Jun 25, 2026 at 8:33 pm

---

🚅 Deployed to the secure-exec-pr-129 environment in secure-exec

Service	Status	Web	Updated (UTC)
secure-exec	😴 Sleeping (View Logs)	Web	Jun 25, 2026 at 8:32 pm