Promise resolved from net.Socket 'data' listener doesn't wake the await site

[proggeramlug]

Summary

Handshake completes end-to-end — net.Socket 'connect', 'data' events fire, our dispatcher processes every frame — and the Promise resolver (startupGate.resolve(conn)) is invoked on the correct object, but the await connect(...) site in async function main() never resumes. Process hangs indefinitely.

Reproduces on 0.5.87, 0.5.88, 0.5.89, 0.5.91 — predates the asm-sideeffect fix in #74.

Repro — full driver path

Repo: https://github.com/PerryTS/postgres — examples/cold-start-minimal.ts:

import { connect } from '../src';

async function main(): Promise<void> {
    const conn = await connect({
        host: '127.0.0.1', port: 55432,
        user: 'perch_test', database: 'perch_test',
    });
    await conn.query('SELECT 1');
}
main().then(() => process.exit(0)).catch(() => process.exit(1));

Against a real Postgres on 127.0.0.1:55432. Bun and Node complete this in <50ms. Perry hangs forever.

What the traces show

With console.log traces inserted into the driver's event dispatch path, on Perry:

[trace] onSocketConnect id=1
[trace] sendStartup writing
[trace] sendStartup written
[trace] onSocketData id=1 len=432
[trace] onSocketData frames.length=17
[trace] handleFrame type=82 paylen=4       # AuthenticationOk
[trace] handleFrame type=83 paylen=19      # ParameterStatus × 15
[trace] handleFrame type=83 paylen=21
...
[trace] handleFrame type=83 paylen=21
[trace] handleFrame type=75 paylen=8       # BackendKeyData
[trace] handleFrame type=90 paylen=1       # ReadyForQuery — auth+setup done
(hangs here)

Inside handleReadyForQuery, we pull the resolver local and call it:

const rs = st.startupGate.resolve;     // never been observed to be null
st.startupGate = null;
rs(st.connection);

No exception is thrown. The trace after rs(...) in handleReadyForQuery executes. But the await connect(...) site in main never resumes — no subsequent traces, no conn.query(...) call, no progress. Process sits idle indefinitely.

Narrower repro (doesn't need Postgres but incomplete)

async function main(): Promise<void> {
    const result = await new Promise<string>((resolve) => {
        setTimeout(() => resolve('from-timer'), 100);
    });
    console.log(result);
}
main();

This works on 0.5.91 — prints from-timer. So a Promise resolved from setTimeout does wake the await. The breaking case is resolving from inside a net.Socket 'data' event handler dispatched through the async stdlib task.

I suspect the issue is specific to how the async bridge (crates/perry-stdlib/src/common/async_bridge.rs) queues the callback back to the main thread — maybe the JSValue is being created on a tokio worker thread, crossing the thread-local-arena boundary noted in the comment:

// IMPORTANT: perry-runtime uses thread-local arenas for memory allocation.
// This means JSValue objects created on tokio worker threads will be allocated
// from a different arena than the main thread, causing memory corruption.

The resolve value (st.connection) is a JSValue object that was created on the main thread, but maybe the resolve() call itself is happening on the tokio thread via the socket event dispatch path.

Repro environment

• Perry 0.5.91 (also 0.5.87–0.5.89)
• macOS 26.4
• Postgres 16 on localhost:55432, perch_test user, trust auth

Impact

Blocks meaningful per-query benchmarking of the @perry/postgres driver on Perry. Bun+Node bench numbers are current; Perry numbers can't be collected until this resolves.

Happy to add more trace output or test candidate fixes.

[proggeramlug]

Fixed in v0.5.92 (c85b348).

Diagnosis: This isn't actually an await wake-up bug — await connect(...) does resume correctly. Instrumented trace on the issue's exact repro (examples/cold-start-minimal.ts against a real Postgres on 127.0.0.1:55432) showed:

1. promise_resolve_fn fires with the correct captured promise pointer (0x...203c8).
2. js_promise_resolve runs — state transitions to Fulfilled.
3. The await loop's next js_promise_state poll returns 1, exits through settled → done, and js_promise_value returns the Connection object.
4. main() continues, calls conn.query('SELECT 1'), returns.
5. .then(() => process.exit(0)) fires — and process.exit(0) silently no-ops.
6. The event loop keeps spinning because js_stdlib_has_active_handles reports the still-open socket → process hangs indefinitely.

Root cause: Codegen never dispatched process.exit(...) — it fell through to generic NativeMethodCall which returns undefined. The runtime function js_process_exit (in perry-runtime/src/process.rs, calls _exit(code as i32)) was defined but unreachable.

Fix (5-place change mirroring the existing process.chdir / process.kill wiring): new Expr::ProcessExit(Option<Box<Expr>>) in HIR, detected in lower.rs alongside chdir/kill, LLVM lowering emits call void @js_process_exit(double %code) with 0.0 default, plus matching emits in perry-codegen-js (passthrough) and perry-codegen-wasm (undefined stub).

Verified: 10/10 runs of examples/cold-start-minimal.ts now exit cleanly with code 0 against a real Postgres; pre-fix they hung indefinitely. 108 runtime tests + 38 perry CLI tests + 49 codegen/hir/wasm/js tests pass; gap suite unchanged at 14/28 · 117 diffs.

The await-is-broken theory in the original report was misleading because the driver-internal trace stops at handleReadyForQuery's rs(...) call — downstream of that, await connect() does resume, conn.query() does run, main() completes, but process.exit(0) can't kill the process so nothing visible happens afterward. The "no conn.query() call, no progress" observation was a visibility gap, not an actual stall.

[proggeramlug]

Thanks — verified v0.5.92 wires process.exit correctly, previous hang is gone.

I was mis-reading my own trace when I filed #75 though. With the exit fix landed, the real bug is now visible: await new Promise<Result>((r) => setTimeout(() => r(objLiteral))) returns a stub empty object before the timer fires, so the driver's handshake completes but the Connection object handed back has every field undefined.

Filed as #77 with a standalone, no-Postgres repro.

[proggeramlug]

Closed by c85b348 (v0.5.92).