[robobun]

Problem

All four node:http server timeout knobs are accepted, stored, and silently unenforced: headersTimeout, requestTimeout, server.setTimeout() (and the 'timeout' event), and keepAliveTimeout. A slow or idle client holds its connection open indefinitely regardless of what the server configured, which is the exposure these knobs exist to prevent (slowloris, dead proxies, fd exhaustion). maxRequestsPerSocket, closeAllConnections() and closeIdleConnections() already worked.

Reproduction: each knob set to 400 ms, probed for 1.8 s

import http from 'node:http';
import net from 'node:net';
function probe(name, setup, firstWrite) {
  return new Promise(res => {
    const srv = http.createServer({ connectionsCheckingInterval: 100 }, (q, r) => { q.resume(); q.on('end', () => r.end('ok')); });
    let closedAt = null; const t0 = Date.now();
    setup(srv);
    srv.on('timeout', s => { s.destroy(); });
    srv.on('clientError', (e, s) => s.destroy());
    srv.listen(0, '127.0.0.1', () => {
      const s = net.connect(srv.address().port); s.setNoDelay(true); s.on('error', () => {}); s.resume();
      s.on('connect', () => { if (firstWrite) s.write(firstWrite); });
      s.on('close', () => { closedAt = Date.now() - t0; });
      setTimeout(() => { try{s.destroy();}catch(e){} srv.close();
        res({ name, serverClosedConnAfterMs: closedAt, enforced: closedAt !== null && closedAt < 1500 }); }, 1800);
    });
  });
}
const out = [];
out.push(await probe('headersTimeout=400', s => { s.headersTimeout = 400; s.requestTimeout = 600; }, 'GET / HTTP/1.1\r\nHost: a\r\n'));
out.push(await probe('server.setTimeout(400)', s => s.setTimeout(400), ''));
out.push(await probe('requestTimeout=400', s => { s.requestTimeout = 400; s.headersTimeout = 300; }, 'POST / HTTP/1.1\r\nHost:a\r\nContent-Length: 50\r\n\r\nab'));
out.push(await new Promise(res => {
  const srv = http.createServer((q, r) => { q.resume(); r.end('ok'); });
  srv.keepAliveTimeout = 400; let closedAt = null; let t0 = 0;
  srv.listen(0, '127.0.0.1', () => {
    const s = net.connect(srv.address().port); s.setNoDelay(true); s.on('error', () => {}); s.resume();
    s.on('connect', () => s.write('GET / HTTP/1.1\r\nHost:a\r\n\r\n'));
    s.once('data', () => { t0 = Date.now(); s.on('close', () => closedAt = Date.now() - t0); });
    setTimeout(() => { try{s.destroy();}catch(e){} srv.close();
      res({ name: 'keepAliveTimeout=400', serverClosedConnAfterMs: closedAt, enforced: closedAt !== null && closedAt < 1500 }); }, 1800);
  });
}));
console.log(JSON.stringify(out));

On bun 1.4.0 and main, every probe reports {"serverClosedConnAfterMs":null,"enforced":false}. On Node v26 they close at 529 / 404 / 504 / 1394 ms. With this change: 1039 / 1471 / 475 / 401 ms (the extra second on the first two is the listen socket's 1 s TCP_DEFER_ACCEPT holding back the accept of a client that sent an incomplete head, which is unrelated to the knobs).

Cause

Two halves, both needed:

1. The JS layer only learned a connection existed once its first request was fully parsed (onNodeHTTPRequest). A socket that never sends a complete request head was invisible to JS, so nothing could time it out. There was no accept hook.
2. The parts JS did have were stubs. setupConnectionsTracking ran an interval whose callback was a literal no-op, NodeHTTPServerSocket.prototype.setTimeout() returned this without arming anything, and Server.prototype.setTimeout forwarded to the uWS per-app idle timeout, which has 4 second granularity (us_socket_timeout rounds seconds with (s + 3) >> 2) and closes the socket natively without reaching the JS 'timeout' event.

Fix

uWS / native: add an onSocketOpen callback to HttpContext, fired on accept (after the TLS handshake for https), next to the existing onSocketClosed / onSocketData Node compat callbacks. Plumbed through the C API (uws_app_set_on_socket_open), uws_sys, and the server crate as Server__setOnNodeSocketOpen, and exposed to node:_http_server as a new optional sixth argument of the existing setServerCustomOptions internal binding. It is only registered when that argument is a function, so Bun.serve is unaffected.

node:_http_server:

• onServerSocketOpen wraps every accepted socket in a NodeHTTPServerSocket and emits 'connection' at accept like Node.js (previously it fired on the first parsed request, and never for CONNECT).
• The connectionsCheckingInterval sweep is now Node's checkConnections: a connection past headersTimeout with an incomplete head, or past requestTimeout with an incomplete request, raises ERR_HTTP_REQUEST_TIMEOUT through 'clientError'. With no listener the server answers 408 Request Timeout and destroys the socket, matching Node's default handler. The request clock stops when the incoming request is complete (at the head for body-less requests, at the body's 'end' otherwise), not when the response finishes, so requestTimeout never kills a slow handler or a long-lived response stream.
• socket.setTimeout() / socket._unrefTimer() are a real per-socket millisecond inactivity timer. server.setTimeout(ms) stores server.timeout and each accepted socket arms it; keepAliveTimeout re-arms it when a response finishes and the connection goes idle. The timer is unref'd and cleared on close.
• ERR_HTTP_REQUEST_TIMEOUT is appended to ErrorCode.ts, so existing error code indices are unchanged.

One knowing deviation from Node: the headersTimeout / requestTimeout clock is anchored at accept, where Node anchors it at the first parsed byte of a message (so Node never times out a connected-but-fully-silent socket). Accept is the event we can observe, is never later than the first byte, and is the stricter of the two for shedding idle connections.

Every accepted connection now allocates its Duplex wrapper at accept rather than lazily at the first parsed request. That is required for any of these timeouts to cover a socket that never completes a request, and it is what Node.js does.

Tests

test/js/node/http/node-http-server-timeouts.test.ts: one test per knob, plus the default 408 answer when there is no 'clientError' listener, plus a regression guard that requestTimeout does not fire while a slow handler is still streaming its response. Five of the six fail on the unmodified build (the guard intentionally passes both ways). Every probe awaits the server closing the connection rather than sleeping, so an unenforced knob fails by timing out.

test/js/node/http/ (221 tests) and the test/js/node/test/parallel/test-http-{timeout,keep-alive,server-}* suite (20 files) pass with no new failures.

Fixes #17287

[coderabbitai]

Warning

Review limit reached

@autofix-ci[bot], we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 18 minutes and 16 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 03151f00-4570-4c7e-bd83-a40d2677d643

📥 Commits

Reviewing files that changed from the base of the PR and between 0f9331d and 1ab6ff9.

📒 Files selected for processing (12)

• packages/bun-uws/src/App.h
• packages/bun-uws/src/HttpContext.h
• packages/bun-uws/src/HttpContextData.h
• src/js/internal/http.ts
• src/js/node/_http_server.ts
• src/jsc/bindings/ErrorCode.ts
• src/jsc/bindings/NodeHTTP.cpp
• src/runtime/server/mod.rs
• src/runtime/server/server_body.rs
• src/uws_sys/App.rs
• src/uws_sys/libuwsockets.cpp
• test/js/node/http/node-http-server-timeouts.test.ts

---

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

[robobun]

^{Updated 5:14 PM PT - Jun 27th, 2026}

❌ @autofix-ci[bot], your commit 1ab6ff9 has 1 failures in Build #65851 (All Failures):

• scripts/build/ci.ts - build failed on :freebsd: aarch64 - build-rust
• scripts/build/ci.ts - build failed on :freebsd: x64 - build-rust
• scripts/build/ci.ts - build failed on 🐧 x64-baseline - build-rust
• scripts/build/ci.ts - build failed on 🐧 x64-musl - build-cpp
• scripts/build/ci.ts - build failed on 🍎 x64 - build-rust

---

🧪   To try this PR locally:

bunx bun-pr 32942

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

bun-32942 --bun

[github-actions]

Found 3 issues this PR may fix:

1. Fastify timeout settings not respected when using Bun runtime with NestJS and Fastify adapter #17287 - Fastify timeout settings (keepAliveTimeout, connectionTimeout) not respected on node:http servers — this PR enforces those previously no-op knobs
2. Node http.createServer can 100% CPU after day uptime in Bun 1.3.13 and 1.4.0 #32600 - http.createServer 100% CPU after long uptime due to stale/idle keep-alive connections never being reaped — fixed by keepAliveTimeout enforcement
3. Express: req/res/socket 'close' events never fire on client abort for POST requests with a body #28976 - Express req/res/socket close events never fire on client abort for POST requests — this PR's onSocketOpen and request lifecycle tracking fixes the socket lifecycle path these events depend on

If this is helpful, copy the block below into the PR description to auto-close these issues on merge.

Fixes #17287
Fixes #32600
Fixes #28976

🤖 Generated with Claude Code

[github-actions]

This PR may be a duplicate of:

1. node:http/https/http2: raise Node v26.3.0 compat to ~94%, sync the upstream suites, and fix the Windows/macOS transport-layer teardown bugs they exposed #32488 - Also implements headersTimeout/requestTimeout enforcement with connectionsCheckingInterval sweep, keepAliveTimeout idle connection closing, and server.setTimeout()/req.setTimeout()/res.setTimeout() real per-socket timers as part of a broader Node v26.3.0 compat PR

🤖 Generated with Claude Code

[robobun]

Checked the three suggestions before adding closing keywords, since those auto-close issues on merge:

• Fastify timeout settings not respected when using Bun runtime with NestJS and Fastify adapter #17287 is covered: Fastify's connectionTimeout calls server.setTimeout() and its keepAliveTimeout sets server.keepAliveTimeout, both of which were no-ops before this change. Added Fixes #17287 to the description.
• Node http.createServer can 100% CPU after day uptime in Bun 1.3.13 and 1.4.0 #32600 has no reproduction, and its profile points at a tick/microtask queue spin (processTicksAndRejections, fixed_queue.shift). Enforcing keepAliveTimeout may reduce how often it is hit by reaping idle sockets, but nothing here touches that queueing path, so I am not claiming it.
• Express: req/res/socket 'close' events never fire on client abort for POST requests with a body #28976 is 'close' not firing when a client aborts an in-flight POST. That is a close-detection problem on a paused request body in the native layer, which this PR does not change, so I am not claiming it either.

[robobun]

Closing in favor of #32488, which predates this PR and already implements everything here as part of a much larger node:http compat pass: headersTimeout / requestTimeout with the connectionsCheckingInterval sweep and the raw 408 reply, keepAliveTimeout, real per-socket timers for server.setTimeout / res.setTimeout / req.setTimeout including TLS, and 'connection' at accept time, validated against Node v26.3.0's own http suites. A competing subset of that is not useful.

One piece that may still be worth taking from this branch: test/js/node/http/node-http-server-timeouts.test.ts is a small standalone test of the four knobs against a raw socket, including a regression guard that requestTimeout stops when the incoming request is complete rather than when the response finishes, so a slow handler or long-lived response stream never gets a spurious 408.

[claude]

🔴 The per-socket inactivity timer is armed once at the request head (line 604) but never reset as request body chunks arrive, so server.setTimeout(ms) behaves as a wall-clock timer rather than an inactivity timer during uploads. With server.setTimeout(5000), a client uploading a 30-second body in continuous chunks will have 'timeout' fire after 5s and the socket destroyed mid-upload, even though bytes are actively flowing — Node.js resets the timer on every incoming read. Fix: call socket._unrefTimer() in onDataIncomingMessage (or wherever body chunks are pushed to the IncomingMessage).

Extended reasoning...

What the bug is

server.setTimeout(msecs) is documented (and behaves in Node.js) as an inactivity timer: it fires only when no bytes have moved on the socket for msecs milliseconds. In Node.js, every incoming chunk goes through onStreamRead, which calls stream[kUpdateTimer]() → socket._unrefTimer(), refreshing the timer. So an actively-uploading client never trips server.timeout no matter how long the total upload takes.

In this PR the timer is armed exactly once per request, at the head:

// _http_server.ts onNodeHTTPRequest, lines 599-605
socket[kHeadersCompleted] = true;
if (socket[kRequestStart] === 0) socket[kRequestStart] = DateNow();
if (socket.timeout !== server.timeout) {
  socket.setTimeout(server.timeout || 0);
} else {
  socket._unrefTimer();
}

After that, request body chunks flow through handle.ondata → onDataIncomingMessage (_http_incoming.ts:370-386), which only does this.push(chunk) and never touches socket._unrefTimer(). There are no _unrefTimer calls anywhere in _http_incoming.ts, and for normal (non-CONNECT/upgrade) requests socket[kEnableStreaming](false) clears the socket's own handle.ondata, so the body bypasses NodeHTTPServerSocket.#onData entirely.

Why existing code doesn't prevent it

_onTimeout()'s only suppression check is for outgoing backpressure:

if (response && response.writableLength > 0) {
  this._unrefTimer();
  return;
}

It does not check whether incoming reads are in progress, so an upload with an empty response buffer falls straight through to this.emit('timeout') → onNodeHTTPServerSocketTimeout, which destroys the socket if no listener swallows it (or hands it to the user's server.setTimeout callback, which conventionally also destroys it).

Bun's own net.ts Socket does call _unrefTimer() on every data chunk, matching Node — it's only the NodeHTTPServerSocket body path that misses it.

Step-by-step proof

1. const server = http.createServer((req, res) => { req.pipe(res); }); server.setTimeout(5000, s => s.destroy()); server.listen(0);
2. Client connects → onServerSocketOpen → socket.setTimeout(5000) arms kTimeoutHandle = setTimeout(socketOnTimeoutFire, 5000, socket).
3. Client sends POST / HTTP/1.1\r\nHost: a\r\nContent-Length: 30000\r\n\r\n → onNodeHTTPRequest runs, calls socket._unrefTimer() once (re-arms 5000ms).
4. Client sends 1KB of body every 1s for 30s. Each chunk reaches onDataIncomingMessage → this.push(chunk). Nothing calls socket._unrefTimer().
5. At t≈5s after the head, socketOnTimeoutFire(socket) → socket._onTimeout() → response.writableLength is likely 0 (small chunks flush immediately) → this.emit('timeout') → onNodeHTTPServerSocketTimeout → server's 'timeout' listener destroys the socket.
6. The upload is aborted at byte ~5000 of 30000 even though bytes were arriving every second. Node.js would never fire 'timeout' here because each chunk would have reset the 5s timer.

Impact

Any node:http server that calls server.setTimeout(N) (or sets server.timeout = N) and accepts uploads longer than N ms will spuriously destroy active uploads. This is opt-in (default server.timeout is 0), but it's the very feature this PR exists to implement, and server.setTimeout + file uploads is a common combination. It is not a regression (socket.setTimeout was a no-op before), but it makes the newly-implemented knob incorrect for the upload case.

Fix

Call this.socket?._unrefTimer() inside onDataIncomingMessage whenever a chunk arrives (mirroring Node's onStreamRead → kUpdateTimer), e.g.:

function onDataIncomingMessage(chunk, isLast, aborted) {
  if (aborted === NodeHTTPResponseAbortEvent.abort) { this.destroy(); return; }
  this.socket?._unrefTimer();
  if (chunk && !this._dumped) this.push(chunk);
  if (isLast) emitEOFIncomingMessage(this);
}

(or equivalently in the NodeHTTPResponse data path). Outgoing writes should similarly reset the timer, but that's a separate concern from this finding.

[claude]

🔴 When two HTTP/1.1 requests are pipelined in one packet and request #1's handler calls res.end() synchronously, request #1's deferred 'finish' → resOnFinish runs after onNodeHTTPRequest has set up request #2's timeout state on the same socket, and unconditionally clobbers it: kRequestStart is zeroed (so request #2 escapes requestTimeout) and socket.setTimeout(keepAliveTimeout) overwrites server.timeout (so a slow async handler on request #2 gets the default 5s keep-alive timer and onNodeHTTPServerSocketTimeout may destroy the socket mid-request). Node.js's resOnFinish guards this via state.outgoing.length === 0; the equivalent here is if (socket._httpMessage) return; before the keep-alive bookkeeping (since res1.end() already detachSocket'd, a non-null _httpMessage means res2 is attached).

Extended reasoning...

What the bug is

resOnFinish (src/js/node/_http_server.ts:1755-1771) unconditionally resets per-socket timeout state to "keep-alive idle":

socket[kRequestStart] = 0;
socket[kHeadersCompleted] = false;
const keepAliveTimeout = server.keepAliveTimeout;
if (keepAliveTimeout) socket.setTimeout(keepAliveTimeout);
else socket._unrefTimer();

But res.end() emits 'finish' via process.nextTick, so for sync-pipelined requests this runs after the next request's onNodeHTTPRequest has already armed the same fields on the same socket, clobbering them.

Code path

uWS explicitly supports sync pipelining (HttpContext.h onData → consumePostPadded: "We still support sync pipelining"). With two requests in one TCP segment:

1. onNodeHTTPRequest(req1) runs. The user handler calls res1.end() synchronously.
2. res1.end() (ServerResponse.prototype.end): the native handle.end() clears HTTP_RESPONSE_PENDING; detachSocket(socket) clears socket._httpMessage = null; 'finish' is scheduled via process.nextTick.
3. onNodeHTTPRequest(req1) returns with handle.finished true → no promise → the parser continues.
4. onNodeHTTPRequest(req2) runs on the same socket: sets socket[kHeadersCompleted] = true, socket[kRequestStart] = DateNow(), calls socket.setTimeout(server.timeout || 0), and assignSocketInternal(http_res2, socket) sets socket._httpMessage = res2.
5. onNodeHTTPRequest(req2) then calls drainMicrotasks() (line ~691), which drains the nextTick queue (Bun's Bun__drainMicrotasksFromJS → GlobalObject::drainMicrotasks() drains nextTickQueue).
6. res1's 'finish' fires now → resOnFinish(server, socket, res1): res1[kMustCloseConnection] is false and socket is alive, so it writes socket[kRequestStart] = 0, socket[kHeadersCompleted] = false, and socket.setTimeout(server.keepAliveTimeout) (default 5000 ms).

Why nothing prevents it

Node.js's resOnFinish guards keep-alive arming with else if (state.outgoing.length === 0) — i.e. only when no further response is queued on the socket. This implementation has no such guard; it assumes 'finish' for response N always precedes the bookkeeping for request N+1, which sync pipelining violates.

Impact

For request #2 on the pipelined socket:

• requestTimeout is bypassed. checkConnections does const start = socket[kRequestStart]; if (!start) continue; — with kRequestStart zeroed, request Fix calling #private() functions in classes #2 is never checked even if its body stalls forever.
• keepAliveTimeout (default 5s) replaces server.timeout. If request Fix calling #private() functions in classes #2's handler is async and takes > 5s with no 'timeout' listener on req/res/server, socketOnTimeoutFire → _onTimeout → onNodeHTTPServerSocketTimeout calls this.destroy(), dropping a live in-flight request.

(Note: kHeadersCompleted=false does not spuriously trip headersTimeout, because kRequestStart=0 makes the sweep skip the socket entirely.)

The trigger — HTTP/1.1 pipelining with a synchronously-handled first request — is uncommon in browsers but reachable from raw TCP clients, proxies, and load-test tools, and the maxRequestsPerSocket code path's own comment acknowledges "already-pipelined requests, which still need to be dispatched".

Step-by-step proof

1. Client sends in one packet: GET /a HTTP/1.1\r\nHost:x\r\n\r\nPOST /b HTTP/1.1\r\nHost:x\r\nContent-Length:50\r\n\r\n (no body bytes for /b yet).
2. Handler for /a does res.end('ok') synchronously.
3. Parser dispatches /b: onNodeHTTPRequest sets socket[kRequestStart]=now, socket[kHeadersCompleted]=true, socket.setTimeout(server.timeout||0), attaches res2, then drainMicrotasks().
4. Inside drainMicrotasks(), res1 'finish' fires → resOnFinish zeroes kRequestStart, sets kHeadersCompleted=false, calls socket.setTimeout(5000).
5. Client never sends /b's body. checkConnections sees start=0 → continue. requestTimeout never fires. Meanwhile, after 5s, socketOnTimeoutFire → onNodeHTTPServerSocketTimeout: req2.complete is false so it emits 'timeout' on req2; if nothing handles it, the socket is destroyed.

Fix

Skip the keep-alive idle bookkeeping when another response is already attached to the socket:

function resOnFinish(server, socket, res) {
  if (res[kMustCloseConnection]) { socket?.end(); return; }
  if (!socket || socket.destroyed) return;
  // The next pipelined request may already be attached; do not clobber its state.
  if (socket._httpMessage) return;
  socket[kRequestStart] = 0;
  socket[kHeadersCompleted] = false;
  ...
}

res1.end() calls detachSocket synchronously, so by the time res1's 'finish' runs, socket._httpMessage is non-null only if assignSocketInternal has attached res2 — exactly the case to guard.

[claude]

🟡 This PR removes the only consumers of kDeferredTimeouts (the import here and the deferred-replay loop in kRealListen/setTimeout), but the symbol is still declared at src/js/internal/http.ts:92 and exported at :547 with no remaining importers. The setServerIdleTimeout re-export in internal/http.ts (:14/:33/:590) is similarly orphaned now that _http_server.ts no longer imports it. Per the root CLAUDE.md ("Delete dead code in the same PR that makes it dead"), both should be removed in this PR.

Extended reasoning...

What

Before this PR, src/js/node/_http_server.ts imported kDeferredTimeouts from internal/http and used it in two places: Server.prototype[kRealListen] replayed any {msecs, callback} entries queued in this[kDeferredTimeouts] once the native server existed, and Server.prototype.setTimeout pushed onto that array when called before listen(). This PR rewrites setTimeout to simply store this.timeout = msecs (which is read per-socket at accept time), so the deferred queue is no longer needed and both the import and the replay loop are deleted.

That deletion was the only consumer of kDeferredTimeouts. After this PR, a repo-wide grep shows exactly two remaining hits, both in src/js/internal/http.ts:

src/js/internal/http.ts:92:const kDeferredTimeouts = Symbol("deferredTimeouts");
src/js/internal/http.ts:547:  kDeferredTimeouts,

No file imports it. The symbol is now an unused module-level const plus an unused named export.

The same applies to setServerIdleTimeout: this PR removes its only JS-side import (_http_server.ts previously called it from Server.prototype.setTimeout). After the PR, the only remaining JS references are the destructure from the native binding at internal/http.ts:14, the type annotation at :33, and the re-export at :590 — none of which has a downstream importer. (The native binding entry in NodeHTTP.cpp and the underlying Server__setIdleTimeout may have reasons to stay for Bun.serve, but the internal/http.ts re-export is dead.)

Step-by-step proof

1. Pre-PR: rg kDeferredTimeouts → 4 hits: declaration + export in internal/http.ts, import + two uses in _http_server.ts.
2. This diff removes the _http_server.ts import (line 30 of the old file) and both use sites (the if (this[kDeferredTimeouts]) replay block in kRealListen and the (this[kDeferredTimeouts] ??= []).push(...) branch in setTimeout).
3. Post-PR: rg kDeferredTimeouts → only internal/http.ts:92 and :547. Nothing reads either.
4. Likewise rg setServerIdleTimeout post-PR → internal/http.ts:14/33/590 and the native NodeHTTP.cpp binding registration; no JS importer of the internal/http export remains.

Why existing code doesn't prevent it

internal/http.ts is bundled into the binary as an internal module, so an unused export is not flagged by any tooling — it just ships dead. Public/exported items escape dead-code lints, which is exactly why the project guideline at CLAUDE.md:237 calls this out:

Delete dead code in the same PR that makes it dead (required scope — name the deletions in the description): … Public items escape dead-code lints — grep for callers manually.

Impact

None at runtime — an unused Symbol() const and an unused export entry have negligible cost. This is purely a code-cleanliness / project-convention issue, hence nit severity. The cost of not cleaning it up is that the next reader of internal/http.ts has to grep to discover the symbol is dead, and a future PR may accidentally resurrect the old (broken) deferral pattern by finding the symbol still exported.

Fix

In src/js/internal/http.ts:

• Delete line 92 (const kDeferredTimeouts = Symbol("deferredTimeouts");).
• Delete the kDeferredTimeouts, entry from the export list at line 547.
• Delete setServerIdleTimeout from the destructure at line 14, the type at line 33, and the export list at line 590.

No test changes needed.

[claude]

🟡 The comment on Server.prototype.getConnections ("Connections are tracked from the first parsed request on each socket (the native server does not surface raw accepts to JS yet)") is now stale: this PR adds onServerSocketOpen, which fires on accept and constructs a NodeHTTPServerSocket whose constructor adds it to kTrackedConnections. Both halves of the comment are now false — please update or drop it.

Extended reasoning...

What the issue is

Server.prototype.getConnections (src/js/node/_http_server.ts:361-362) carries this comment:

// Connections are tracked from the first parsed request on each socket
// (the native server does not surface raw accepts to JS yet).

This PR directly invalidates both factual claims in that sentence, but leaves the comment untouched.

The code path that invalidates it

1. This PR adds an onSocketOpen hook to uWS (HttpContext.h onOpen/onHandshake), plumbed through uws_app_set_on_socket_open → App::on_socket_open → Server__setOnNodeSocketOpen → the new sixth argument of setServerCustomOptions.
2. Server.prototype[kRealListen] now passes onServerSocketOpen.bind(this) as that sixth argument.
3. onServerSocketOpen runs on every accepted connection (after the TLS handshake for https), before any bytes are parsed, and does new NodeHTTPServerSocket(self, handle, ssl).
4. The NodeHTTPServerSocket constructor calls server[kTrackedConnections]?.add(this).

So after this PR: connections are tracked from accept (not from the first parsed request), and the native server does surface raw accepts to JS. Both halves of the comment are now factually wrong.

Step-by-step proof

• Client connects but sends nothing.
• uWS onOpen fires → httpContextData->onSocketOpen(...) → Rust thunk → on_node_socket_open_callback → JS onServerSocketOpen.
• onServerSocketOpen constructs NodeHTTPServerSocket, whose constructor runs server[kTrackedConnections]?.add(this).
• server.getConnections(cb) now reports 1 for this socket even though no request head has been parsed — directly contradicting the comment's first clause.
• The very existence of onServerSocketOpen being called from native on accept contradicts the parenthetical second clause.

Why nothing prevents it

The PR did not touch getConnections itself, so the comment was simply missed. There is no compile-time or test-time guard that ties comments to behavior.

Impact

Documentation accuracy only — no runtime effect. But it is a specific factual claim (not a vague description) that this PR's central change directly contradicts, and per repo convention comments invalidated by a PR should be updated in the same PR. A future reader debugging getConnections semantics would be actively misled about when tracking begins.

How to fix

Update the comment to reflect the new behavior, e.g.:

// Connections are tracked from accept (onServerSocketOpen adds the
// NodeHTTPServerSocket wrapper to kTrackedConnections before any bytes
// are parsed).

Or simply drop the comment if it no longer adds value.

[claude]

🟡 nit: msecs | 0 coerces to int32, so socket.setTimeout(2_500_000_000) (or any msecs >= 2**31, including server.keepAliveTimeout/server.timeout flowing through here) wraps to a negative number and _unrefTimer's if (msecs > 0) check then leaves the timer disarmed. Node.js's net.Socket.setTimeout (and Bun's own net.ts) instead runs getTimerDuration(msecs, 'msecs'), which clamps to TIMEOUT_MAX = 2**31 - 1 with a TimeoutOverflowWarning. The trigger is a >24.8-day inactivity timeout so the practical impact is negligible, but for parity consider this.timeout = getTimerDuration(msecs, 'msecs') (or at least >>> 0).

Extended reasoning...

What the bug is. NodeHTTPServerSocket.prototype.setTimeout stores the timeout as this.timeout = msecs | 0. The bitwise-OR coerces its operand to a signed 32-bit integer, so any msecs value at or above 2**31 (2147483648) wraps to a negative number — e.g. 2_500_000_000 | 0 === -1794967296. _unrefTimer() then reads this.timeout, sees msecs > 0 is false, and takes the else branch that sets this[kTimeoutHandle] = null instead of arming a setTimeout. The net effect is that asking for a very large inactivity timeout silently disables the timer entirely.

The specific code path. There are three entry points that reach this coercion: (1) a user calling req.socket.setTimeout(N) or res.setTimeout(N) directly on the server socket; (2) server.timeout = N / server.setTimeout(N), which onServerSocketOpen and onNodeHTTPRequest forward to socket.setTimeout(server.timeout); and (3) server.keepAliveTimeout = N, which resOnFinish forwards to socket.setTimeout(keepAliveTimeout) after each response. storeHTTPOptions validates keepAliveTimeout and requestTimeout with validateInteger(..., 0), whose default upper bound is Number.MAX_SAFE_INTEGER, so values ≥ 2^31 pass validation and reach the | 0 truncation unchanged.

Why nothing prevents it. Node.js's net.Socket.prototype.setTimeout (and Bun's own implementation in src/js/node/net.ts:2273) calls getTimerDuration(msecs, 'msecs') from internal/timers, which (a) validates the value is a non-negative number and (b) clamps anything above TIMEOUT_MAX = 2**31 - 1 down to TIMEOUT_MAX while emitting a TimeoutOverflowWarning. The new NodeHTTPServerSocket is a separate Duplex subclass that does not go through net.Socket.prototype.setTimeout, and its | 0 shortcut does not replicate that clamping. Before this PR setTimeout on this class was a no-op, so there was no prior behavior to regress; this is a new divergence introduced alongside the new functionality.

Step-by-step proof.

1. server.keepAliveTimeout = 3_000_000_000 (≈ 34.7 days). storeHTTPOptions calls validateInteger(3_000_000_000, 'keepAliveTimeout', 0) → passes (≤ MAX_SAFE_INTEGER).
2. A request is served; on response 'finish', resOnFinish(server, socket, res) runs with keepAliveTimeout = 3_000_000_000, which is truthy, so it calls socket.setTimeout(3_000_000_000).
3. setTimeout does this.timeout = 3_000_000_000 | 0 → -1294967296, then calls this._unrefTimer().
4. _unrefTimer reads msecs = -1294967296, clears any existing handle, evaluates msecs > 0 → false, sets this[kTimeoutHandle] = null. No timer is armed.
5. In Node.js the same call would store socket.timeout = 2147483647, emit a TimeoutOverflowWarning, and arm a ~24.8-day unref'd timer.

Impact. The behavioral divergence is real but the practical impact is minimal. 2^31 ms ≈ 24.8 days; no realistic socket inactivity, keep-alive, or server timeout approaches that (defaults are 0 / 5 s; generous deployments use minutes). The functional difference between "no timer" and "timer fires after 24.8 days" is essentially nil — the peer, OS keepalive, or process restart will close the connection long before either fires. Node itself treats this range as out-of-bounds and only warns. This is why the refuting verifier deems it non-actionable; we agree it does not block the PR, but it is still a correctness/parity gap worth noting.

Fix. Match net.Socket.setTimeout: import getTimerDuration from internal/timers and write this.timeout = msecs === 0 ? 0 : getTimerDuration(msecs, 'msecs') (Node treats 0 as "disable" without going through getTimerDuration, and server.timeout || 0 already passes 0 for the disabled case). A lighter alternative that avoids the warning machinery is this.timeout = Math.min(msecs >>> 0, 2 ** 31 - 1), but getTimerDuration is the established pattern in this codebase.