node:net: make resetAndDestroy() throw ERR_INVALID_HANDLE_TYPE on TLS and pipe sockets

[robobun]

Problem

• socket.resetAndDestroy() on a tls.TLSSocket or on a unix socket / named pipe connection resets and destroys the socket. Node throws TypeError [ERR_INVALID_HANDLE_TYPE]: This handle type cannot be sent synchronously for both (client or server side, connected or still connecting) and only resets plain TCP sockets.
• On a new tls.TLSSocket(socket) that has not started yet, the call went even further off: the reset ran and failed inside _destroy with this._handle.terminate is not a function, delivered as the socket's 'error'.
• Cause: Socket.prototype.resetAndDestroy in src/js/node/net.ts has no equivalent of node's if (!(this._handle instanceof TCP)) throw new ERR_INVALID_HANDLE_TYPE() (lib/net.js, v26.3.0 L801-L815). Bun cannot use the handle's class for this: the native handle is the same TCPSocket class for a TCP and for a unix / named-pipe connection.

Fix

• resetAndDestroy() throws $ERR_INVALID_HANDLE_TYPE() when the socket has a handle and is either a tls.TLSSocket (recognized by its class, the same check Ipc.ts uses to refuse sending a TLS socket) or a pipe connection. The check sits before the connecting branch, like node's.
• Pipe connections are recorded in a per-socket flag (kIsPipe) at the points where net.ts decides the transport, which is where node would construct a Pipe instead of a TCP handle:
  • Socket.prototype.connect(): the path option; the fd branch sets it to false. Every connect() call decides it, so a reused socket follows its current connection;
  • onconnection: the listener's bound path (handle.unix), or kClusterUnixPath for a cluster worker accepting on the primary's shared fd (the two sources Server.prototype.address() already reads);
  • onClusterConnection (round-robin cluster worker): the path kClusterFauxListen stores on the faux handle, set after the connect({ fd }) that cleared it.
• Why this is correct: it matches node. Every TLSSocket with a handle has a TLS wrap there, so the class is the exact predicate; for pipes, node's handle type is itself derived from the same path / listen-path decisions, so recording that decision reproduces it. The plain net.Socket underneath tls.connect({ socket }) keeps a TCP handle in node and stays resettable here too.
• Not covered, on purpose: connections adopted from a bare descriptor (connect({ fd }), listen({ fd }), IPC-received sockets) count as TCP, where node inspects the descriptor type; and a TLSSocket that has no handle at all yet (bare new tls.TLSSocket(), tls.connect({ socket }) over a still-connecting socket, or a server-side new tls.TLSSocket(socket, { isServer: true }) in the tick before its upgrade attaches) takes the existing no-handle branch (destroy(ERR_SOCKET_CLOSED)) where node, which wraps eagerly, throws. Both follow from how bun attaches handles, not from this check, and nothing in the repo calls resetAndDestroy() on either.
• Verified (every new test fails on the released build and passes with this branch):
  • test/js/node/net/node-net.test.ts, "resetAndDestroy() handle type": unix socket / named pipe while connecting, connected, and on the accepting side throw; TCP still resets in all three states; a socket reused for TCP after a pipe connection resets again.
  • test/js/node/tls/node-tls-connect.test.ts, "TLSSocket.resetAndDestroy()": tls.connect() before and after the handshake, the server's socket, tls.connect({ socket }) over a net.Socket and over a Duplex, and a not-yet-started new TLSSocket(stream) all throw; the wrapped net.Socket still resets.
  • test/js/node/cluster.test.ts: SCHED_RR and SCHED_NONE workers; the unix-path server's accepted socket throws, the TCP server's resets.
  • Full node-net.test.ts: the same 11 failures as without the change in this container (connect(port) localhost resolution and unref tests), nothing new. node-tls-connect.test.ts, cluster.test.ts, child_process_ipc_handle.test.ts, and the proxy tests whose fixtures call resetAndDestroy() on a TLS server socket inside a try/catch (proxy-stress-lifecycle.test.ts, proxy-stress-adversarial.test.ts, the handshake-reset cases in proxy.test.ts; on the TLS legs they now take their destroy() fallback, since bun does not expose a _parent to reset instead): all pass.
  • Vendored test/js/node/test/parallel/test-net-*reset*.js (8 files) pass; the full test-net-* / test-tls-* set has no failures attributable to the change.

Background

• resetAndDestroy() (added in node 18.3) closes a TCP connection with an RST instead of a FIN; in node it calls TCP.prototype.reset, which only TCP handles have, hence the handle-type guard. Bun implements the RST with the native terminate(), which exists on every native handle, so nothing stopped the call from going through.
• Node handle types: a net.Socket wraps a TCP handle (TCP connection), a Pipe handle (unix domain socket, or named pipe on Windows), or for tls.TLSSocket a TLSWrap around one of those. this._handle instanceof TCP is how node tells them apart; bun's native handle is a TCPSocket or TLSSocket object regardless of the address family underneath.
• Symbol.for("::buntls::") (bunTlsSymbol): a method defined on tls.TLSSocket.prototype (and on tls.Server) that net.ts uses throughout to detect TLS sockets; new tls.TLSSocket, tls.connect() and server-accepted TLS sockets are all instances of that class.
• Cluster workers accept connections in two ways: under SCHED_RR the primary accepts and hands each connection's fd to a worker, which wraps it via a faux listen handle (onClusterConnection); under SCHED_NONE the worker listens on the primary's shared fd, so the native listener has no path and the server records it in kClusterUnixPath.

Probe output (node v26.3.0 vs bun 1.4.0 vs this branch)

case                                          node 26.3.0                 bun 1.4.0 (release)                          this branch
tcp connecting                                no throw, destroyed=false   no throw, destroyed=false                    no throw, destroyed=false
tcp connected                                 no throw, destroyed=true    no throw, destroyed=true                     no throw, destroyed=true
unix client connecting                        ERR_INVALID_HANDLE_TYPE     no throw, destroyed=false                    ERR_INVALID_HANDLE_TYPE
unix client connected                         ERR_INVALID_HANDLE_TYPE     no throw, destroyed=true                     ERR_INVALID_HANDLE_TYPE
unix server-side accepted                     ERR_INVALID_HANDLE_TYPE     no throw, destroyed=true                     ERR_INVALID_HANDLE_TYPE
tls.connect() connecting                      ERR_INVALID_HANDLE_TYPE     no throw, destroyed=false                    ERR_INVALID_HANDLE_TYPE
tls.connect() after secureConnect             ERR_INVALID_HANDLE_TYPE     no throw, destroyed=true                     ERR_INVALID_HANDLE_TYPE
tls server-side accepted                      ERR_INVALID_HANDLE_TYPE     no throw, destroyed=true                     ERR_INVALID_HANDLE_TYPE
tls.connect({ socket }) wrapper               ERR_INVALID_HANDLE_TYPE     no throw, destroyed=true                     ERR_INVALID_HANDLE_TYPE
new tls.TLSSocket(connectedSocket), unstarted ERR_INVALID_HANDLE_TYPE     'error' "_handle.terminate is not a function" ERR_INVALID_HANDLE_TYPE
net.Socket wrapped by tls.connect({ socket }) no throw, destroyed=true    no throw, destroyed=true                     no throw, destroyed=true
new net.Socket() (no handle)                  'error' ERR_SOCKET_CLOSED   'error' ERR_SOCKET_CLOSED                    'error' ERR_SOCKET_CLOSED
new tls.TLSSocket() (no socket, no handle)    ERR_INVALID_HANDLE_TYPE     'error' ERR_SOCKET_CLOSED                    'error' ERR_SOCKET_CLOSED (see "not covered")

---

no test proof · iteration 1 · Platform-specific test(s) that do not run on this machine. Deferring to CI, which covers all platforms: test/js/node/cluster.test.ts test/js/node/net/node-net.test.ts

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 564d83d5-59a2-49f7-8501-d170d6bec9b2

📥 Commits

Reviewing files that changed from the base of the PR and between b5afcac and 9fae45f.

📒 Files selected for processing (4)

• src/js/node/net.ts
• test/js/node/cluster.test.ts
• test/js/node/net/node-net.test.ts
• test/js/node/tls/node-tls-connect.test.ts

---

Walkthrough

Summary

net.ts now tracks pipe handles and limits resetAndDestroy() to TCP sockets. Tests cover Unix sockets, Windows named pipes, clustered connections, TCP connections, and TLS wrappers.

Changes

Handle-aware socket reset

Layer / File(s)	Summary
Track handle types and guard reset behavior src/js/node/net.ts	Socket paths record pipe status. resetAndDestroy() throws ERR_INVALID_HANDLE_TYPE for TLS and pipe sockets.
Validate TCP, pipe, and cluster connections test/js/node/net/node-net.test.ts, test/js/node/cluster.test.ts	Tests cover connection state, server-side sockets, reused sockets, and both cluster scheduling policies.
Validate TLS wrapper behavior test/js/node/tls/node-tls-connect.test.ts	Tests cover TLS sockets before and after handshakes, transport wrappers, and uninitialized wrappers.

Possibly related PRs

• oven-sh/bun#35417: Both changes update socket connection and handle-state tracking in src/js/node/net.ts.

Suggested reviewers: cirospaciari, jarred-sumner

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the primary change to make resetAndDestroy() reject TLS and pipe sockets.
Description check	✅ Passed	The description explains the problem, fix, scope, implementation details, and verification results, including relevant test coverage.

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Status: ready to merge on review; the diff is green, CI is blocked on infrastructure.

Reproduced with the released bun (1.4.0) and node v26.3.0 side by side: resetAndDestroy() on a tls.connect() socket, a server-side TLS socket, a tls.connect({ socket }) wrapper, a not-yet-started new tls.TLSSocket(stream), and on unix-socket connections (connecting, connected, and accepted, plus cluster workers under both scheduling policies) returns normally in bun and throws ERR_INVALID_HANDLE_TYPE in node; plain TCP behaves the same in both. Every new test in test/js/node/net/node-net.test.ts, test/js/node/tls/node-tls-connect.test.ts and test/js/node/cluster.test.ts fails on the released build and passes with this branch.

CI: the last code change is 9fae45f (4528b72 is an empty retrigger). Both builds for it, 95304 and 95829, have 177 of 179 jobs passed with no failing test (the only annotations are tests that passed on retry, none in net/tls/cluster); the remaining two jobs are the two darwin 14 aarch64 - test-bun shards, which expired without an agent in 95304 and have been waiting for one in 95829. Those two shards are the only macOS test lane in the matrix, so the new tests have passed on every Linux lane and on both Windows lanes (which exercise the named-pipe branch) but have not yet run on macOS in CI; the macOS-specific part of the change is only the unix socket path length in the cluster test, which was shortened to fit sun_path with room to spare. I am not going to keep retriggering; if a maintainer wants the two shards re-run, a retry of those jobs is enough.

Related: #34507 has a test that calls resetAndDestroy() on a tls.connect({ socket }) wrapper and expects it to go through; whichever of the two lands second needs that test adjusted (node throws there too).

[robobun]

^{Updated 8:04 AM PT - Aug 14th, 2026}

✅ @robobun, your commit 4528b72de61ba9447c1103591010339d49d15c10 passed in Build #95829! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 38232

That installs a local version of the PR into your bun-38232 executable, so you can run:

bun-38232 --bun

[claude]

LGTM — clean Node compat fix with thorough coverage.

What was reviewed:

• kIsPipe is initialized in the constructor and set at every point where net.ts decides the transport (connect(), onconnection, onClusterConnection); the onClusterConnection assignment correctly follows connect({fd}) so it isn't clobbered.
• The TLS check reuses the existing typeof this[bunTlsSymbol] === "function" idiom already used at four other sites in net.ts, and ERR_INVALID_HANDLE_TYPE is already registered in ErrorCode.ts.
• Checked the one internal resetAndDestroy() caller that hits TLS sockets (test/js/bun/http/proxy-stress-helpers.ts) — it unwraps to the raw TCP socket and already has a catch { client.destroy() } fallback, so it isn't broken by the new throw.

Extended reasoning...

Overview

This PR makes net.Socket.prototype.resetAndDestroy() throw ERR_INVALID_HANDLE_TYPE for TLS sockets and unix/named-pipe sockets, matching Node's if (!(this._handle instanceof TCP)) throw guard. Since Bun's native handle is the same class regardless of transport, a new per-socket kIsPipe symbol records the pipe/TCP decision at the four points where net.ts makes it: the Socket constructor (init to false), connect() (from options.path), onconnection (from handle.unix || self[kClusterUnixPath], the same two sources Server.prototype.address() reads), and onClusterConnection (from the faux handle's unix). TLS is detected with the existing bunTlsSymbol prototype-method check.

Security risks

None. This tightens an API to throw where it previously succeeded; it does not relax any check, touch credential handling, or affect trust decisions.

Level of scrutiny

Moderate — a Node-compat behavioral change in src/js/node/net.ts that turns a previously-succeeding call into a synchronous throw, and threads new per-socket state through four code paths including two cluster-worker accept paths. That said, the change is small (~30 production lines), follows established idioms in the file, and the check placement (inside if (this._handle), before the connecting branch) mirrors Node's exactly.

Other factors

• Test coverage is comprehensive across the variant matrix the review guidelines call for: pipe vs TCP × connecting/connected/accepted, TLS via tls.connect() / server-side / tls.connect({socket}) over both net.Socket and Duplex, cluster SCHED_RR and SCHED_NONE, and a reused socket switching pipe→TCP. Each asserts the exact error name/code/message and destroyed state.
• The PR description includes a probe table diffed against Node v26.3.0, and confirms the vendored test-net-*reset*.js parallel tests and the full node-net/node-tls/cluster/proxy-stress-lifecycle suites still pass.
• The one subtlety I checked — that socket[kIsPipe] = !!this.unix in onClusterConnection runs after socket.connect({fd}) (which resets kIsPipe to false since no path is passed) — is correctly ordered.
• The acknowledged gap (fd-adopted sockets are treated as TCP where Node inspects the descriptor type) is stated in the PR body and does not regress anything.

[robobun]

One correction to the review's reasoning: in the pushed revision connect({ fd }) returns before the kIsPipe assignment, so it did not reset the flag; the onClusterConnection ordering only mattered defensively. A reused socket going pipe -> connect({ fd }) would have kept a stale flag. I have a follow-up commit that sets the flag to false on the fd branch too, so every connect() call decides it; pushing it together with anything the remaining review turns up.

[claude]

I reviewed this PR and didn't find any bugs. The kIsPipe bookkeeping and the guard in resetAndDestroy() look correct and are thoroughly tested against Node v26.3.0. Because it's a user-visible behavioral change (calls that previously succeeded now throw) in the core node:net compat layer, and there are outstanding comment-cop findings plus an acknowledged interaction with #34507, a human look would still be worthwhile.

What was reviewed:

• kIsPipe is set on every path that decides the transport (connect() path/fd branches, onconnection, onClusterConnection) and initialized in the constructor — no stale-flag window on socket reuse.
• The TLS check via bunTlsSymbol matches how the rest of net.ts detects TLSSocket; the underlying net.Socket in a tls.connect({ socket }) wrap correctly stays resettable.
• Existing in-tree resetAndDestroy() callers on TLS sockets (proxy-stress-helpers.ts) already fall back to destroy() in a try/catch; tls-low-prio-queue-fixture.ts uses plain net.connect TCP sockets, so it's unaffected.

Extended reasoning...

Overview

Adds a Node-compat guard to Socket.prototype.resetAndDestroy() in src/js/node/net.ts: it now throws ERR_INVALID_HANDLE_TYPE synchronously for TLS sockets and unix-socket / named-pipe connections, matching Node's if (!(this._handle instanceof TCP)) check. Since Bun's native handle class is the same for TCP and pipe connections, the transport is recorded in a new per-socket kIsPipe symbol at each site that decides it (client connect(), server onconnection, cluster onClusterConnection, and reset on the connect({ fd }) early-return branch). Three test files gain coverage for pipe vs TCP × connecting/connected/accepted, socket reuse, TLS wrappers over both a net.Socket and a Duplex, and both cluster scheduling policies.

Security risks

None. This narrows an API's accepted inputs (fails closed on non-TCP handles) rather than widening it, and touches no auth/crypto/trust decisions.

Level of scrutiny

Medium-high. src/js/node/net.ts is core Node compat surface used by http, tls, cluster, and user code; the change is small but flips previously-succeeding calls to a synchronous throw. That's the correct Node behavior, and the failure mode for anyone relying on the old behavior is loud (a TypeError with a specific code), but it is still a user-facing behavioral change that a maintainer should sign off on.

Other factors

• Five outstanding comment-cop inline findings from github-actions[bot] flag the new explanatory comments as too long; those haven't been addressed yet.
• The author flagged an interaction with #34507, whose test expects resetAndDestroy() on a tls.connect({ socket }) wrapper to succeed — whichever lands second needs adjusting.
• I checked the other in-tree resetAndDestroy() callers: proxy-stress-helpers.ts already wraps the call in try/catch with a destroy() fallback (and unwraps to the raw TCP socket first), tls-low-prio-queue-fixture.ts calls it on plain TCP net.connect sockets, and _http_server.ts's is a no-op stub on FakeSocket — none regress.
• Test coverage is strong: the new tests assert the exact error class/code/message, cover both connection states and both sides, verify the flag is decided per-connect(), and were confirmed to fail on the released build.

[robobun]

Pushed the follow-ups (head is now 9fae45f):

• connect({ fd }) sets the flag to false as well, so every connect() call decides it (7ede0a1).
• One more TLS shape covered: new tls.TLSSocket(stream).resetAndDestroy() before the handshake starts. On the released build that call went through and failed inside _destroy with this._handle.terminate is not a function (surfaced as the socket's 'error'); it now throws ERR_INVALID_HANDLE_TYPE like node (93d1862).
• Comments trimmed to one line each; the inline threads are resolved (39ea98d, 9fae45f).
• Cluster test uses shorter names so the absolute socket path stays well inside sun_path with a default macOS TMPDIR (39ea98d).
• PR body updated: the not-covered list now also names listen({ fd }) and the server-side new TLSSocket(socket, { isServer: true }) pre-upgrade tick, and the verified list includes the proxy tests whose fixtures reset a TLS server socket inside a try/catch (they take their destroy() fallback on the TLS legs now).

No logic changes beyond the first bullet.

[claude]

LGTM — a focused Node.js compat fix with thorough coverage.

What was reviewed:

• The kIsPipe flag is set at every transport-decision point (connect() path/fd branches, onconnection via handle.unix/kClusterUnixPath, onClusterConnection via the faux handle's unix) and read only in resetAndDestroy(); the bunTlsSymbol check matches the pattern used elsewhere in net.ts and Ipc.ts.
• $ERR_INVALID_HANDLE_TYPE() produces the exact TypeError/code/message the tests assert (via ErrorCode.cpp).
• In-repo resetAndDestroy() callers on TLS sockets (proxy-stress-helpers.ts rstClient) already wrap in try/catch with a destroy() fallback, so no existing tests regress.
• Tests await real events, clean up in try/finally, and cover the connecting/connected/server-side/reused/cluster matrix plus the TLS wrap shapes.

Extended reasoning...

Overview

Adds a private kIsPipe symbol on net.Socket to record whether the underlying transport is a unix socket / named pipe (vs TCP), and guards Socket.prototype.resetAndDestroy() to throw ERR_INVALID_HANDLE_TYPE for TLS sockets (detected via bunTlsSymbol, the same predicate Ipc.ts uses) and for pipe sockets. This mirrors Node's if (!(this._handle instanceof TCP)) guard, which Bun cannot reproduce directly because its native handle class doesn't distinguish TCP from pipe. The flag is set at each point where net.ts decides the transport: connect() (both the path and fd branches), onconnection (server accept, reading handle.unix || self[kClusterUnixPath]), and onClusterConnection (round-robin cluster worker, reading the faux handle's unix set by kClusterFauxListen). Tests are added in three files covering unix/TCP × connecting/connected/server-side, socket reuse, both cluster scheduling policies, and every TLS wrap shape (tls.connect(), server-side, tls.connect({ socket }) over a net.Socket and a Duplex, and an unstarted new TLSSocket(stream)).

Security risks

None. This is a Node compat behavioral change (throwing where Bun previously silently reset). No auth, crypto, permissions, or untrusted-input parsing is touched. The added flag is a private symbol only read by resetAndDestroy().

Level of scrutiny

Medium. It's a Node compat fix in the well-trodden src/js/node/net.ts layer with a narrow surface: one new symbol, five one-line flag assignments at existing transport-decision points, and a two-line guard in resetAndDestroy(). The behavior change is user-visible (a throw where there wasn't one), but it aligns Bun with Node's documented contract, and the only in-repo TLS callers (proxy-stress-helpers.ts rstClient) already wrap the call in try/catch with a destroy() fallback — the PR description confirms those tests pass. No native code, memory management, or hot-path perf concerns.

Other factors

• The bunTlsSymbol check (typeof this[bunTlsSymbol] === "function") is the same idiom used throughout net.ts and in Ipc.ts for the same purpose.
• $ERR_INVALID_HANDLE_TYPE() is defined in ErrorCode.ts/ErrorCode.cpp and produces TypeError with code ERR_INVALID_HANDLE_TYPE and message "This handle type cannot be sent", matching the tests' exact-string assertions.
• The author self-identified and fixed the stale-flag case where connect({ fd }) returned before the flag assignment (7ede0a1), so every connect() call now decides the flag.
• All comment-cop threads were addressed (comments trimmed to one line each; all threads resolved).
• Tests follow the repo's conventions: once() for events, try/finally cleanup, port: 0, exact error class/code/message assertions, and a per-connect() reuse test to prove the flag isn't stale. The PR description documents verification against node v26.3.0, USE_SYSTEM_BUN=1 failure, and the vendored test-net-*reset*.js suite.
• Not covered by CODEOWNERS.

[claude]

Automated review ran and found no bugs. Deferring to a human because this is a user-visible behavior change to resetAndDestroy() (previously-working calls on TLS and pipe sockets now throw) and introduces per-socket kIsPipe state that must stay in sync at every handle-attach point in net.ts.

What was reviewed:

• The kIsPipe flag is derived from the same sources Server.prototype.address() already reads (handle.unix / kClusterUnixPath), and every connect() path (fd, path, host/port) decides it.
• The TLS check reuses the bunTlsSymbol pattern already used in Ipc.ts for the same error code; $ERR_INVALID_HANDLE_TYPE() produces the exact node message the tests assert.
• The onClusterConnection assignment after connect({ fd }) and the fd-branch reset — checked that the ordering is right so the RR worker's flag reflects the faux handle's unix.
• Tests cover the variant matrix (connecting/connected/server-side, pipe→TCP reuse, both cluster policies, all TLS shapes) and assert TCP still resets.

Extended reasoning...

Overview

The PR adds a handle-type guard to Socket.prototype.resetAndDestroy() in src/js/node/net.ts so it throws ERR_INVALID_HANDLE_TYPE for TLS sockets and unix/named-pipe connections, matching node's if (!(this._handle instanceof TCP)) check. Since bun's native handle class does not distinguish TCP from pipe, a new per-socket kIsPipe symbol records the transport at each point net.ts decides it: the Socket constructor (default false), connect({ fd }) (false), connect({ path }) vs host/port, onconnection (from the listener's handle.unix / kClusterUnixPath), and onClusterConnection (from the faux handle's unix, after the fd-connect that cleared it). TLS is detected via typeof this[bunTlsSymbol] === 'function', the same pattern Ipc.ts uses for this error. Three test files gain thorough coverage.

Security risks

None identified. The change makes an operation stricter (rejects instead of proceeding) and does not touch verification, credentials, or trust decisions. The TLS check is a class-level predicate, not a security gate.

Level of scrutiny

Moderate-to-high. src/js/node/net.ts is a large hot-path built-in and this is a user-visible behavior change: code that previously called resetAndDestroy() on a TLS or unix socket in bun and had it go through will now get a synchronous throw. The PR verified the in-tree proxy fixtures (which do this inside try/catch) still pass on their fallback path, and the vendored test-net-*reset*.js suite passes, but this is still the kind of compat-vs-existing-users trade-off a maintainer should sign off on. The PR also flags a known conflict with #34507's test.

Other factors

• The runtime diff is small (~15 lines) and follows existing idioms in the file (bunTlsSymbol check, symbol-keyed private state, $ERR_* machinery).
• The kIsPipe derivation reuses exactly the two sources Server.prototype.address() already reads to answer the same question, so it should stay consistent with what the server reports.
• The PR explicitly documents its non-coverage (connect({ fd }), listen({ fd }), IPC-received sockets treated as TCP; a bare new tls.TLSSocket() with no handle takes the ERR_SOCKET_CLOSED branch) — these follow from how bun attaches handles rather than from this check, but they are a documented divergence from node.
• All comment-cop threads are resolved (comments trimmed to one line each in 39ea98d/9fae45f).