connectionId is scoped per-connection, not per-request — misroutes/drops later requests on a reused HTTP/1.1 keep-alive connection

[Hermander741]

Summary

setupMaster's workerId/connectionId are declared once per raw TCP connection (in the closure of httpServer.on("connection", (socket) => { let workerId, connectionId; ... })), not per HTTP request. Once the first request on a connection has a Content-Length or Transfer-Encoding header (mayHaveMultipleChunks), connectionId is set and never reset for the rest of that connection's lifetime — even after that request completes.

Any subsequent request sent over the same reused keep-alive connection then hits:

if (workerId && connectionId) {
  cluster.workers[workerId].send({ type: "sticky:http-chunk", data, connectionId }, sendCallback);
  return;
}

— treated as a continuation chunk of the first request, instead of being routed as a new sticky:connection. On the worker side, if the original socket has already been removed from the sockets map (e.g. because the first request's response already completed and the socket was closed), the later request's entire raw bytes — headers included, not just a body — are silently dropped (sockets.get(connectionId) returns undefined, nothing happens). The client hangs forever: no response, no error, no log output anywhere.

Every browser reuses HTTP/1.1 keep-alive connections by default, so this reproduces reliably against real browser traffic (Chrome) — a client sending a POST/PATCH/PUT with a body, followed by any other request on the same connection, is enough to trigger it. curl mostly avoids it in casual testing only because a fresh CLI invocation typically opens a fresh connection each time — it is not curl-specific, and reproduces the same way with a raw TCP connection carrying two pipelined requests.

Environment

• @socket.io/sticky: 1.0.4 (latest on npm as of this report)
• socket.io: 4.8.3
• Node.js: v24.18.0
• Confirmed via @socket.io/pm2-orchestrated PM2 cluster mode (2 workers) and independently reproduced with vanilla Node cluster + @socket.io/sticky (no PM2 involved at all), ruling out PM2 as a factor.

Minimal reproduction

// repro.js
const cluster = require('cluster')
const http = require('http')
const { setupMaster, setupWorker } = require('@socket.io/sticky')
const { Server } = require('socket.io')

const PORT = 4001

if (cluster.isMaster) {
  cluster.setupMaster({ windowsHide: true })
  const httpServer = http.createServer()
  setupMaster(httpServer, { loadBalancingMethod: 'least-connection' })
  httpServer.listen(PORT, () => console.log(`listening on ${PORT}`))
  cluster.fork()
  cluster.fork()
} else {
  const httpServer = http.createServer((req, res) => {
    let body = ''
    req.on('data', c => { body += c })
    req.on('end', () => {
      console.log(`[worker ${process.pid}] ${req.method} ${req.url} body=${JSON.stringify(body)}`)
      res.writeHead(200, { 'Content-Type': 'application/json' })
      res.end(JSON.stringify({ ok: true, pid: process.pid, method: req.method }))
    })
  })
  const io = new Server(httpServer)
  setupWorker(io)
}

Steps:

1. node repro.js
2. Send a POST with a JSON body, then a second request (any method) reusing the same TCP connection — e.g. two curl requests piped down one raw socket, or via a real browser tab where Chrome's connection pool happens to reuse the socket. A real browser making a POST followed by any other request to the same origin is the easiest way to trigger this in practice — it reproduces reliably against actual application traffic, not just crafted pipelining.
3. The second request hangs indefinitely if the first request's socket has already closed by the time the second request's bytes arrive as a sticky:http-chunk — sockets.get(connectionId) returns undefined in setupWorker, and the request is silently dropped with no error anywhere.

Expected behavior

Each HTTP request on a keep-alive connection should be routed as its own logical unit — workerId/connectionId (or equivalent per-request state) should reset once a request/response cycle completes, so a second request on a reused connection is treated as a fresh request rather than a phantom continuation of the first.

Actual behavior

The second (and any later) request on a connection where the first request carried a Content-Length/Transfer-Encoding header is misrouted as a sticky:http-chunk of the first request. If the first request's socket is no longer tracked, the later request is silently dropped — no response, no error, indefinite hang on the client.

Happy to provide the full diagnostic logs from a live-instrumented reproduction (added temporary console.error calls to index.js and captured the exact message sequence) if useful — omitted here for brevity but readily available.

[Hermander741]

Additional evidence + confirmed against current main

Confirmed the bug is present in main/HEAD as well, not just the published 1.0.4 — fetched index.js directly from the default branch and it's byte-for-byte identical in the relevant section to what's installed via npm.

Concrete log excerpt from a live, instrumented reproduction (added temporary console.error calls to the installed index.js, ran against a real 2-worker cluster, triggered via an actual browser session reusing a keep-alive connection — not a synthetic pipelining test):

[worker] raw message received: type=sticky:connection, hasSocket=true, dataLen=670, connectionId=1f14e13b3d2a85fc
[worker] replaying first chunk, len=670, preview="POST /api/auth/refresh HTTP/1.1\r\nHost: localhost:3001\r\nConnection: keep-alive\r\nContent-Length: 0\r\n..."
...
[worker] raw message received: type=sticky:connection, hasSocket=true, dataLen=551, connectionId=undefined
[worker] replaying first chunk, ... preview="OPTIONS /api/auth/me HTTP/1.1..."
...
[worker] raw message received: type=sticky:http-chunk, hasSocket=false, dataLen=670, connectionId=1f14e13b3d2a85fc
[worker] http-chunk for connectionId=1f14e13b3d2a85fc, socketFound=false, len=670
[worker] http-chunk DROPPED — no socket in map for connectionId=1f14e13b3d2a85fc, known keys=

The connectionId minted for the first request (POST /api/auth/refresh, Content-Length: 0) gets reused as the routing key for a later, completely unrelated request on the same reused connection. By the time that later request's bytes arrive, the original socket has already been removed from the worker's sockets map (its own request/response cycle long completed and closed) — so the second request's full raw bytes, 670 bytes of an actual HTTP request, are silently dropped. socketFound=false, known keys= empty. The client that sent this specific request hangs forever with no response and no error anywhere in the stack.

Suggested root cause / fix direction

let workerId, connectionId; is declared once per httpServer.on("connection", (socket) => {...}) invocation — i.e., once per raw TCP connection — and both variables persist for that connection's entire lifetime once set. The header parse that decides mayHaveMultipleChunks (and therefore whether to mint a connectionId) only happens the first time socket.on("data", ...) fires with workerId/connectionId still unset; every later data event on the same socket short-circuits straight into the sticky:http-chunk branch without ever re-parsing the incoming bytes as a potential new request.

The fix likely needs the routing decision to happen per logical HTTP request, not per TCP connection — e.g., resetting workerId/connectionId once the request that owns the current connectionId completes (there's already a natural signal for this on the worker side: socket.on("close", ...) deletes the worker-side map entry, but nothing on the master side is told when a single request/response cycle inside a still-open keep-alive socket finishes, so it has no way to know the next data event is actually a new request rather than a continuation). Possibly: track completion via httpServer.on("request", (req) => req.on("end", ...)) bookkeeping already present for a related purpose, or re-run the mayHaveMultipleChunks-style header sniff on every data event and only treat it as a continuation chunk if the previous request is provably still incomplete (e.g. compare accumulated bytes against the Content-Length seen in the last parsed header block).

Happy to try a patch against a branch if that's useful, though I don't have write access here — let me know if a PR would be welcome.

[Hermander741]

Independent corroboration from a real-world case using this library via @socket.io/pm2: traced a live drop through a real browser session (not synthetic), with direct diagnostic logging on both the master's socket.on("data", ...) handler and the worker's process.on("message", ...) handler.

One connectionId (4eef3c59d2f1e243) across three distinct HTTP exchanges on the same reused connection, over the course of one browser tab's session (a live Socket.IO WebSocket connection open the whole time, plus ordinary page API calls):

received sticky:connection, connectionId=4eef3c59d2f1e243, dataLen=670   → injected, added to worker's sockets map
received sticky:http-chunk,  connectionId=4eef3c59d2f1e243, dataLen=1003 → replayed (map hit)   — 2nd request on this connection succeeded
received sticky:http-chunk,  connectionId=4eef3c59d2f1e243, dataLen=1023 → DROPPED — no matching socket in map

Worth noting since the three payload lengths differ (670 / 1003 / 1023) — this rules out (at least for this trace) a "duplicate delivery of the same original request's bytes" explanation; each of the three was a genuinely distinct request, and the third was the one that vanished. The dropped request was a real form submission through the application's UI — confirmed nothing reached the app layer at all (zero server-side log output, zero DB query activity, and the record the request should have created was never persisted).

Also confirms this isn't a PM2-specific artifact — same failure class as your PM2-free minimal repro, just observed through the @socket.io/pm2-orchestrated path instead.

[darrachequesne]

Thanks for the detailed analysis 👍

This should be fixed by efd3445, included in @socket.io/sticky@2.0.0. Could you please check?