pydantic/monty · error · Error
Monty wasm component requested process exit
Error message
Monty wasm component requested process exit
What it means
The WASI component running the Monty worker called `process.exit` (e.g. via an OOM path or guest-requested exit). Instead of letting that terminate the whole Node process, denyProcessExit converts it into an ordinary JS Error so the pool layer can treat it as a component failure and recover.
Source
Thrown at crates/monty-js/ts/worker/host.ts:70
exit: denyProcessExit,
exitWithCode: denyProcessExit,
},
'wasi:cli/stderr': imports['wasi:cli/stderr'],
'wasi:cli/stdin': imports['wasi:cli/stdin'],
'wasi:cli/stdout': imports['wasi:cli/stdout'],
'wasi:clocks/monotonic-clock': imports['wasi:clocks/monotonic-clock'],
'wasi:clocks/wall-clock': imports['wasi:clocks/wall-clock'],
'wasi:filesystem/preopens': imports['wasi:filesystem/preopens'],
'wasi:filesystem/types': imports['wasi:filesystem/types'],
'wasi:io/error': imports['wasi:io/error'],
'wasi:io/streams': imports['wasi:io/streams'],
'wasi:random/random': imports['wasi:random/random'],
}
}
/** Turns a guest exit into a component failure instead of terminating Node. */
function denyProcessExit(): never {
throw new Error('Monty wasm component requested process exit')
}
/** Resolves Jco's relative core-module path against the precompiled module map. */
function getModule(modules: ComponentModules, path: string): WebAssembly.Module {
const module = modules[path] ?? modules[path.replace(/^\.\//, '')]
if (!module) throw new Error(`component core module is missing: ${path}`)
return module
}
View on GitHub (pinned to adc986b362)
Solutions
- Inspect the sandboxed code for memory-exhausting patterns and set/raise max_memory appropriately
- Treat the thrown error as a worker crash: recreate the pool/session and retry the workload
- If reproducible with small inputs, report it — a benign script should never reach the exit syscall
Example fix
// before
await session.feedRun(hugeInputCode)
// after
try {
await session.feedRun(code, { maxMemory: 64 * 1024 * 1024 })
} catch (e) {
pool = await Monty.create() // replace crashed worker
} Defensive patterns
Strategy: try-catch
Validate before calling
null
Type guard
null
Try / catch
try { await session.feedRun(code) } catch (e) { if (e.message.includes('requested process exit')) { await pool.close(); pool = await Monty.create(); /* retry once */ } else throw e } Prevention
- Set a realistic max_memory so guest code exits gracefully with MemoryError instead of hitting the hard limit
- Profile sandboxed scripts for unbounded allocations before deploying
- Always recreate the pool/session after this error — the worker is not reusable
- Keep the wasm worker packages in sync to avoid guest/host version skew
When it happens
Trigger: Running the wasm worker path when the guest requests process exit — typically the hard memory-limit path (monty-alloc OOM handling calls exit) or an internal guest abort.
Common situations: Browser/Node wasm runs where sandboxed code exhausts max_memory; bugs in guest code paths that reach an exit syscall; users seeing this surfaced as a session/pool error rather than a dead process.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- memoryUsageLimit must be a non-negative safe integer
- component core module is missing: ${path}
- Monty.create could not auto-load the monty wasm module in th
- the wasm worker does not support filesystem mounts (browser
- Dump returned an unexpected event
AI-assisted analysis of pydantic/monty@adc986b362 (2026-09-13).
Data as JSON: /api/errors/ec20fca2685ef67f.
Report an issue: GitHub.