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

  1. Inspect the sandboxed code for memory-exhausting patterns and set/raise max_memory appropriately
  2. Treat the thrown error as a worker crash: recreate the pool/session and retry the workload
  3. 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

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


AI-assisted analysis of pydantic/monty@adc986b362 (2026-09-13). Data as JSON: /api/errors/ec20fca2685ef67f. Report an issue: GitHub.