fix(v8-bridge): yield a macrotask between bridge socket reads (undici keep-alive leak)

[NathanFlurry]

Problem

The in-VM bridge socket read loop (_pumpBridgeReads in crates/execution/assets/v8-bridge.source.js) is async but contained no await. Because _netSocketReadRaw is synchronous, the loop drained every available byte and emitted readable/data for an entire HTTP response in one synchronous burst.

That collapses the event-loop turn boundaries undici's keep-alive socket recycling depends on:

1. undici's H1 parser reaches onMessageComplete in the same synchronous stack.
2. It resolves the caller's fetch synchronously, and only defers socket reuse with setImmediate(client[kResume]).
3. The caller's await fetch() continuation (a microtask) dispatches the next request before that setImmediate macrotask runs.
4. Every pooled Client is still kNeedDrain, so Pool.kGetDispatcher constructs a new Client + socket per request.

Each new Client registers ~4 EventEmitter listeners, so the count climbs until it trips MaxListenersExceededWarning and the in-VM Node process exhausts memory and is OOM-killed (the V8 isolate's 128 MiB heap cap fires near_heap_limit_callback → terminate_execution). It only reproduces in the VM because real Node delivers response bytes across multiple I/O turns, so setImmediate(kResume) reliably fires before the next request.

Fix

await a setImmediate-backed macrotask yield before delivering each payload, so socket bytes surface across distinct event-loop turns — exactly as on real Node where each readable arrives in its own I/O callback. This lets setImmediate(kResume) clear kNeedDrain before the next dispatch, so the pool reuses one keep-alive socket.

Empirically (from the original investigation): 40 sequential requests went from 40 sockets / 41 Clients to 1 socket / 2 Clients.

The single v8-bridge.source.js feeds both the execution and v8-runtime crates, so both pick up the fix from one source.

Test

Adds a deterministic regression test to the javascript_v8 suite that scripts two socket chunks over the mocked net bridge and schedules a setImmediate (standing in for setImmediate(kResume)) the instant the first chunk lands. It asserts the macrotask interleaves before the second chunk:

• Synchronous-burst bug → trace data:chunk-1,data:chunk-2,immediate → guest throws → test fails.
• Fixed → trace data:chunk-1,immediate,data:chunk-2 → test passes.

Verified both directions locally (reverting the source edit reproduces the failure).

[railway-app]

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

Service	Status	Web	Updated (UTC)
secure-exec	😴 Sleeping (View Logs)		Jun 24, 2026 at 4:15 pm

---

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

Service	Status	Web	Updated (UTC)
secure-exec	😴 Sleeping (View Logs)	Web	Jun 24, 2026 at 4:14 pm