[pyramation]

Merge #173 first. This branch includes #173, because on main the v13 CI job tests the wrapper bundled in @libpg-query/v13@13.5.7, not this repo's source. Without #173 the v13 recovery test ran against that old wrapper and hung. Once #173 is in main, its commits drop out of this diff.

Summary

Before: in every published build (17.7.4, 18.1.5 and the lowmem tags), one bad input could permanently break the parser for the rest of the process.

• If an exception escapes a WASM call, libpg_query's cleanup never runs. The exception can be a V8 RangeError (stack overflow on deeply nested SQL), a trap, or Emscripten's exit() when the 1 GiB heap limit is hit.
• Each such exception leaks the C shadow stack and the whole parse memory context.
• Repeat a deep input about 35 times (SELECT 1+1+…, 100k terms, 25 ms each) and the instance traps on every later call, including SELECT 1.
• The heap-limit path is worse: it throws ExitStatus, which is not an Error, and silently sets process.exitCode = 1 in the host process.

Change: JS wrapper only. No WASM rebuild and no memory-flag change.

resultPtr = callWasm(() => wasmModule._wasm_parse_query_raw(queryPtr));

function callWasm(fn) {
  const exitCode = process?.exitCode;
  try { return fn(); }
  catch (error) {
    wasmModule = undefined;          // the instance's state is unknown; drop it
    initPromise = instantiate();     // load a fresh one (10–25 ms)
    process.exitCode = exitCode;     // undo exit()'s side effect
    if (error instanceof Error) throw error;
    throw new Error('libpg_query terminated (…), most likely out of WASM memory; …', { cause: error });
  }
}

• finally blocks skip _free once the instance has been dropped.
• Async entry points loop while (!wasmModule) await (initPromise ?? instantiate()). That includes a call already queued behind the failing one, so it waits for the fresh instance.
• A *Sync call made during the 10–25 ms reload throws the existing "Call loadModule() first" error.
• If the reload itself fails, initPromise is cleared, so the next call retries. The failed promise always has a handler, so it never becomes an unhandled rejection that kills the process.
• Only throws that unwind out of WASM trigger a reload. A SqlError from a normal parse error is built in JS after the call returns, so it does not.

Reproduced first: the new test/wasm-recovery.test.js runs in every version (13–18).

• Stays usable: 60 deep-chain failures, then parseSync('SELECT 1'). On the current build, call 34 ends in RuntimeError: table index is out of bounds, and so does SELECT 1 afterwards.
• Heap limit: a 50 MB 'SELECT 1;\n' input must reject with an Error, leave process.exitCode unchanged, and still parse SELECT 1. Before the fix it threw RuntimeError (after the first test) or ExitStatus with process.exitCode = 1.
• Queued call: parse(deep) and parse('SELECT 1') run concurrently, and the second must succeed. Before the fix it got "Call loadModule() first".
• Failed reload: tested by hand with a stub loader that fails on its 2nd call. Before the fix, the process died with an unhandled rejection, or every later call rejected forever. Now the next call reloads and parses.
• After the fix: v18 95/95, v17 44/44, v13 44/44 pass locally.

These are the two wrapper bugs the memory-defaults research found; that research's harness is on the research/wasm-memory branch. Separately, the prebuilt v13 WASM still uses Emscripten's 64 KiB stack and traps on a 1000-term 1+1+…. With this PR it recovers instead of staying broken.

Link to Devin session: https://app.devin.ai/sessions/bcd8b2f791164247acb7a659b481efc2
Open in Devin Desktop: https://app.devin.ai/desktop/session/bcd8b2f791164247acb7a659b481efc2?variant=devin
Requested by: @pyramation

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[tenki-reviewer]

Review complete. 🟡 2 medium

💬 Inline comments (2)

• 🟡 Concurrent callers fail spuriously during WASM recovery window — index.ts:144
• 🟡 Recovery instantiate() rejection is left unhandled — index.ts:145

---

This PR wires a recovery path into the WASM wrappers: callWasm catches native aborts/OOM, nulls the module, re-instantiates it, and retries or rethrows, and each version gains a wasm-recovery test suite exercising OOM and stack-overflow recovery.

Files	Change
templates/index.ts, templates/full/index.ts	Add callWasm guard/recovery logic used to regenerate the per-version wrappers.
versions/{13..18}/src/index.ts	Regenerated from templates; identical recovery semantics across versions.
versions/{13..18}/package.json	Append wasm-recovery suite to test scripts (18 keeps its extra suites).
versions/{13..18}/test/wasm-recovery.test.js	New resource-exhaustion tests: large multi-statement OOM input and repeated stack-overflow loop asserting recovery via loadModule().

_{Reviewed commit: 01c4459}

[tenki-reviewer]

Adds WASM crash-recovery (re-instantiation on OOM/abort) and recovery tests across the six pg_query versions, with two medium-severity gaps in the recovery window left to address.

Key findings

• 🟡 Concurrent callers fail spuriously during WASM recovery window — index.ts:144
• 🟡 Recovery instantiate() rejection is left unhandled — index.ts:145