process: execArgv fix, getActiveResourcesInfo with sockets/servers/fs, _getActiveHandles/_getActiveRequests (+9 tests, process 85%→94%)

[cirospaciari]

Two node:process fixes, verified against the node v26.3.0 binary. Adds 9 vendored upstream tests.

execArgv -- terminator

create_exec_argv re-parses argv and kept the -- terminator, so a process started as bun --flag -- app.js reported -- in process.execArgv where node does not — which also broke round-tripping through fork(). Fixed at both sites (main-thread re-parse and the explicit-worker branch). The re-parse tracks the pending option value as explicit state: -- consumed as a value (bun --conditions -- app.js) is kept, a bare -- is dropped, and a value that merely spells a value-taking option cannot keep a later -- alive. The value-taking set holds clap's One/Many options only; OneOptional flags such as --inspect take a value via = alone, so a -- after them is the terminator. The same logic runs on the main-thread re-parse and on the worker execArgv override.

Active resource tracking

getActiveResourcesInfo(), process._getActiveHandles() and process._getActiveRequests() were stubs returning []. Now backed by real state:

• Timers: 'Timeout' per ref'd setTimeout/setInterval, 'Immediate' per pending setImmediate, from a dedicated js_timeout_ref_count — not active_timer_count, which is also bumped by the c-ares retry ticker and Bun.spawn({timeout}) and produced phantom entries.
• Sockets/servers/fs: a live node:net handle registry (internal/active_handles.ts, intrusive doubly-linked list keyed by symbols — register/unregister allocate no GC cells) reports 'TCPServerWrap'/'TCPSocketWrap' ('PipeWrap' on unix transports, kept through client- and server-side TLS wraps), 'FSReqCallback' from a per-thread count of in-flight async fs requests, and 'GetAddrInfoReqWrap'/'GetNameInfoReqWrap' for in-flight dns.lookup/lookupService in both callback and promise forms, and assembles the _getActiveHandles/_getActiveRequests objects. unref()'d handles are excluded, ref() re-includes, nextTick is not counted, matching node's measured semantics.
• http.Server rides Bun.serve (no net.Server underneath), so it registers with the active-handle registry directly as TCPServerWrap/PipeWrap in _http_server.ts. Remaining documented limits: during a net.Server listening callback Bun reports one real 'Timeout' where node uses nextTick, and a child process's IPC channel (which node lists as a 'PipeWrap', e.g. inside a cluster worker) is not registered yet; a round-robin cluster worker's own server is deliberately not registered, matching node, whose faux handle is not a HandleWrap either.

Verification

The vendored tests run verbatim, 3x each, failing on system bun as a control; tamper mutations fail correctly (using replaceAll — three first-pass tampers landed in comments and were redone). Measured with file-redirected stdout because two of the upstream files fail on real node when stdout is a pipe (PipeWrap becomes an active handle). Regressions: 105/105 vendored test-{process,stdout,stdin,stdio}*.

Fixes #25387

Compat impact (upstream node v26.3.0 test files vendored, in-tree = passing)

• node:process: 85% → 94% (83 → 92 of 98)

Merge with main

Main moved AsyncFSTask and AsyncReaddirRecursiveTask onto the bun_jsc::Job model, removing the create/destroy pairs the fs request counter hooked into. Both job types share the AsyncFSJs JS-side half, so the counter now lives there: AsyncFSJs::new increments and its Drop decrements, which covers normal completion and release-unrun at teardown alike. UVFSRequest and the cp task keep the explicit pairing at ref/unref. The cp completion keeps its scope guard (main still destroys after the fallible conversion arms); the readdir guard is gone because main's completion takes the task by value. The worker execArgv truncation was rebuilt over main's worker_option_string. It compares -- and option names against the latin1 view for 8-bit entries and against a narrowed copy for 16-bit entries whose units are all ASCII (is_8bit() is the storage encoding, not the content: a string decoded from UTF-16 bytes carries ASCII in 16-bit storage); entries with non-ASCII units are ordinary tokens. Verified: all nine vendored tests, the in-tree registry/execArgv tests, and a probe driving every async fs task type (including a rejecting cp) back to a zero count.

A later sync with main (bc713f9, bun_core::String owning its WTF ref) turned worker_option_string into an owning String, so the worker execArgv array builder now hands each element to the JSString with into_js instead of to_js; with the returned +1 from clone_latin1/clone_utf16, to_js would have ref'd a second time and leaked one ref per element. The truncation loop is unchanged. Re-verified with the same vendored tests, in-tree tests, fs counter probe, and a worker probe covering non-ASCII tokens.

---

no test proof · iteration 23 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/js/node/process/process.test.js

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/js/internal/active_handles.ts`:
- Around line 33-36: Replace direct Map method calls on pendingRequestWraps with
the intrinsic .$set(), .$values(), and .$keys() methods throughout the request
registry, including noteRequestStart and the inspection paths around the
referenced usages. Preserve the existing registration and iteration behavior
while ensuring all pendingRequestWraps access bypasses potentially modified
Map.prototype methods.

In `@test/js/node/process/process.test.js`:
- Around line 1580-1582: Update test/js/node/process/process.test.js lines
1580-1582 and 2413-2419 to drain proc.stderr.text() concurrently with
proc.stdout.text() and proc.exited via Promise.all. At both sites, validate the
expected stderr before parsing stdout; in lines 2413-2419 parse JSON from
stdout.trim(), and keep the exit-code assertion last.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: ecea9782-9e0e-4483-8a0f-0aed91675ceb

📥 Commits

Reviewing files that changed from the base of the PR and between da04506 and e1cabd8.

📒 Files selected for processing (4)

• src/js/internal/active_handles.ts
• src/js/node/net.ts
• src/runtime/node/node_process.rs
• test/js/node/process/process.test.js

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

test/js/node/process/process.test.js (1)

2345-2349: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Assert child stderr before handling stdout.

Both tests drain stderr but do not validate it. In the second test, stderr is only an expect() message. A child diagnostic can then be hidden by a stdout assertion or JSON parse failure.

• test/js/node/process/process.test.js#L2345-L2349: Assert expect(stderr).toBe("") before asserting stdout.
• test/js/node/process/process.test.js#L2410-L2416: Assert expect(stderr).toBe("") before testing or parsing stdout.

As per coding guidelines, subprocess tests must drain and validate stderr before stdout handling, with the exit-code assertion last. Based on learnings, bunEnv makes the empty-stderr assertion stable here.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/js/node/process/process.test.js` around lines 2345 - 2349, The
subprocess assertions in test/js/node/process/process.test.js at lines 2345-2349
and 2410-2416 must validate stderr before handling stdout: add
expect(stderr).toBe("") immediately after draining stderr in both tests, then
retain the existing stdout assertions or parsing, with the exitCode assertion
last; ensure the processes use bunEnv so the empty-stderr expectation remains
stable.

Sources: Coding guidelines, Learnings

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/js/node/process/process.test.js`:
- Around line 2392-2415: Update the inline TLS client test around tls.connect
and the setImmediate callback to retain the returned TLS socket, then use
bounded polling until process._getActiveHandles().includes(tlsSocket) is true.
Assert this registration condition before reading
process.getActiveResourcesInfo(), while preserving the existing resource-kind
assertions and clean process exit.

---

Outside diff comments:
In `@test/js/node/process/process.test.js`:
- Around line 2345-2349: The subprocess assertions in
test/js/node/process/process.test.js at lines 2345-2349 and 2410-2416 must
validate stderr before handling stdout: add expect(stderr).toBe("") immediately
after draining stderr in both tests, then retain the existing stdout assertions
or parsing, with the exitCode assertion last; ensure the processes use bunEnv so
the empty-stderr expectation remains stable.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: f2241f0b-b456-489c-830a-10c94089993f

📥 Commits

Reviewing files that changed from the base of the PR and between a7ed4a2 and e4dabb2.

📒 Files selected for processing (3)

• src/js/internal/active_handles.ts
• src/js/node/net.ts
• test/js/node/process/process.test.js

[claude]

I reviewed this PR and the bug-hunting pass found no new issues; every prior thread is resolved and the latest commit (66c07eb) adds the requested rationale comment for the post-close setTimeout. Because the change is large and threads registration/unregistration through hot socket-lifecycle paths (notably the new stale-handle early return in SocketHandlers2.close) plus reorders native async-task teardown in node_fs.rs via scopeguard, a human look is still worthwhile.

What was reviewed:

• internal/active_handles.ts intrusive list — double-register/unregister idempotence, iteration under lazy prune, $arrayPush/$set tamper hardening.
• net.ts register/unregister placement across connect/open/close/destroy/TLS-wrap arms; the SocketHandlers2.close stale-handle guard falls through on _handle == null so post-destroy close tail work still runs.
• node_fs.rs PENDING_ASYNC_REQUESTS inc/dec pairing across all four task types and the scopeguard-based destroy() reorder in AsyncCpTask/AsyncReaddirRecursiveTask::run_from_js_thread.
• create_exec_argv -- handling for value-taking vs OneOptional params on both the main-thread and worker-override branches.

Extended reasoning...

Overview

Two node:process fixes across 22 files: (1) process.execArgv no longer includes the -- terminator, with a state-machine re-parse that distinguishes value-consuming options from OneOptional ones; (2) getActiveResourcesInfo() / _getActiveHandles() / _getActiveRequests() are now backed by real state — a new internal/active_handles.ts intrusive-list registry wired through net.ts, _http_server.ts, and dns.ts; a per-thread js_timeout_ref_count in the timer subsystem; and a PENDING_ASYNC_REQUESTS thread-local in node_fs.rs. Nine vendored upstream tests plus ~170 lines of Bun-side tests in process.test.js.

Security risks

None identified. The active-handles registry is per-VM JS state keyed by symbols; it exposes live socket/server objects via _getActiveHandles() (matching Node's underscore-prefixed introspection contract), and the tamper-hardening passes ($set/$delete/$forEach/$arrayPush, literal kind argument to noteRequestStart) close the prototype-pollution surface prior review rounds flagged. No auth, crypto, permission, or path-handling changes.

Level of scrutiny

High. This is not a mechanical change: it weaves registerHandle/unregisterHandle calls into ~15 sites across net.ts connect/open/close/destroy/TLS-upgrade paths, and adds a behavioral early return to SocketHandlers2.close (if (self._handle != null && socket !== self._handle) return;) that suppresses a superseded handle's close from marking the still-live socket closed. That guard is correct as written (it falls through on _handle == null so ordinary post-destroy close still delivers end/settles pending writes), but socket-close ordering is exactly the kind of path where a subtle regression would surface as a hang or a lost 'end' in real workloads. Separately, node_fs.rs moves Self::destroy(self) in AsyncCpTask::run_from_js_thread and AsyncReaddirRecursiveTask::run_from_js_thread from an explicit call before resolve/reject into a scopeguard armed at function entry — so destroy now runs on the ?-propagated early-return arms too. That's the intended fix (the counter would otherwise leak on those arms), but it changes native teardown ordering in a memory-sensitive path.

Other factors

The PR has been through ~20 iterations with extensive bot review; every prior inline thread is resolved, including the .skipIf(isWindows) question on the unix-socket http.Server test (author resolved without a gate — Windows AF_UNIX filesystem sockets are supported and CI covers it). Test coverage is thorough: 9 upstream tests run verbatim, plus targeted Bun tests for the sync-throw-no-leak case, TLS-wrap PipeWrap preservation (client and server side, gated on registration), and the execArgv value-vs-terminator matrix. Given the breadth of hot-path instrumentation and the native lifecycle refactor, I'm deferring rather than approving.

[claude]

I reviewed this pass and found no new issues; all prior review threads are resolved. Given the scope — the new close-guard in SocketHandlers2.close (net.ts), registration/unregistration threaded through every net.ts/TLS handle-swap path, the per-thread fs request counter on AsyncFSJs/cp lifecycle, and the new js_timeout_ref_count — a maintainer sign-off would still be worthwhile.

Checked this run: the intrusive-list registerHandle/unregisterHandle pairing across connect/destroy/TLS-upgrade/reinitialize paths (unregister is idempotent via the kKind == null guard, and the connect try/catch covers synchronous validation throws); pending_request_begin/end balance on every AsyncFSJs construct/drop and the cp scopeguard; the execArgv -- re-parse for both main-thread and worker-override branches including the OneOptional (--inspect) case; and forEachActive's captured-next traversal surviving in-loop unregisterHandle.

Extended reasoning...

Overview

This PR implements process.getActiveResourcesInfo(), process._getActiveHandles(), and process._getActiveRequests() (previously stubs), and fixes process.execArgv to drop the -- terminator. It touches 22 files across the Rust runtime (node_fs.rs, node_process.rs, timer/{mod,Timer,timer_object_internals}.rs), C++ bindings (BunProcess.cpp), and hot-path JS builtins (net.ts, dns.ts, _http_server.ts, plus a new internal/active_handles.ts). Nine upstream Node tests are vendored and seven in-tree tests added.

Security risks

None identified. The active-handles registry is observability-only; it stores references to objects the user already holds and exposes them back via debugging APIs Node also exposes. No auth, crypto, or permission surfaces are touched. Prior tamper-resistance concerns ($arrayPush, Map intrinsics, noteRequestStart taking a literal kind) have been addressed in earlier iterations.

Level of scrutiny

High. net.ts is one of the most complex, load-bearing files in the Node compat layer, and this PR threads register/unregister calls through ~15 sites including TLS upgrade, family-autoselection reinitialize, server accept, and destroy. It also adds a behavioral guard to SocketHandlers2.close (if (self._handle != null && socket !== self._handle) return) that changes when a superseded handle's close event is suppressed — well-commented and sensible, but not purely additive observability. The Rust side adds a thread-local counter whose increment/decrement must balance across every async-fs task lifetime (normal completion, error, teardown release-unrun), and a new js_timeout_ref_count alongside the existing active_timer_count that must stay in sync with set_enable_keeping_event_loop_alive.

Other factors

The PR has been through ~115 timeline events and multiple review rounds; every prior inline thread from me, CodeRabbit, and cirospaciari is marked resolved. The bug-hunting system found nothing this run. Test coverage is substantial (9 vendored upstream tests + 7 targeted in-tree tests covering ref/unref, TLS wrap kind preservation, synchronous-throw leak, dns promise form). The PR description documents remaining known limits (IPC channel PipeWrap, cluster round-robin worker) and the merge-with-main rebase.

I'm deferring rather than approving because the net.ts close-path change and the breadth of lifecycle hook points across net/TLS/fs/timer are exactly the kind of change where a maintainer with runtime context on net.ts should sign off, and no human approval is on the PR yet.

[claude]

I reviewed this revision and found no new issues — c8fa7ff addresses the last open finding (the worker execArgv scan now narrows 16-bit-stored ASCII via narrow_ascii_u16, with a covering test). Given the scope — 22 files across the timer subsystem, fs async task lifecycle, net.ts socket handlers (including the new superseded-handle early-return in SocketHandlers2.close), and BunProcess.cpp — a human pass is still warranted before merge.

What was reviewed:

• create_exec_argv ---terminator state machine on both main-thread and worker paths, including the 16-bit storage encoding fix and the OneOptional exclusion.
• active_handles.ts intrusive-list register/unregister pairing across net.ts connect/destroy/TLS-wrap arms and _http_server.ts listen/close — no leaked entries found on synchronous throw paths.
• PENDING_ASYNC_REQUESTS counter balance across AsyncFSJs::new/Drop, UVFSRequest, and the cp task's scopeguard-ordered destroy.
• js_timeout_ref_count bookkeeping in set_enable_keeping_event_loop_alive — confirmed it tracks only JS timeout/interval objects, not the DNS retry ticker or spawn timeouts.

Extended reasoning...

Overview

This PR replaces stub process.getActiveResourcesInfo()/_getActiveHandles()/_getActiveRequests() with real backing state and fixes process.execArgv ---terminator handling. It spans 22 files: a new internal/active_handles.ts intrusive-list registry; registration hooks threaded through net.ts (socket open/close/destroy, TLS wrap paths, server listen/close), _http_server.ts, and dns.ts (callback + promise forms); a per-thread PENDING_ASYNC_REQUESTS counter in node_fs.rs hooked into AsyncFSJs/UVFSRequest/cp task lifecycles; a new js_timeout_ref_count in the timer subsystem; BunProcess.cpp LUT changes; and the create_exec_argv rewrite in node_process.rs. Nine vendored upstream Node tests plus in-tree coverage.

Security risks

None identified. The changes are observability/compat surface — no auth, crypto, permissions, or untrusted-input parsing beyond the existing argv re-parse (which reads process argv, not network data). The tamper-resistance of active_handles.ts was already hardened in earlier iterations ($-intrinsics, literal kind arguments).

Level of scrutiny

High. This is not a mechanical change: it threads registration/unregistration calls through ~15 sites in net.ts's socket state machine, adds a behavioral early-return to SocketHandlers2.close (superseded-handle guard), touches timer refcount bookkeeping, and reorders NewAsyncCpTask destroy via scopeguard. Each of these is a hot path where an unbalanced register/unregister or a mis-ordered early-return could leak entries, hang the loop, or regress socket-close semantics. The PR has been through many review iterations (8+ inline findings from prior runs, all now addressed), which itself signals the change is non-trivial.

Other factors

The last outstanding inline finding (16-bit-stored ASCII in the worker execArgv scan) was addressed by c8fa7ff with narrow_ascii_u16 and a dedicated test. All prior inline threads are marked resolved. Test coverage is thorough (9 vendored + 8 in-tree targeted tests including TLS-wrap PipeWrap preservation, synchronous-throw leak checks, and the encoding edge case). The PR description documents known remaining limits (IPC PipeWrap, cluster faux-listen). I am deferring rather than approving because the surface area — particularly the net.ts close-handler behavioral change and the fs task lifecycle reordering — merits a maintainer's eye, not because any specific defect remains.