René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"http: ClientRequest highWaterMark option not propagated to OutgoingMessage","articleBody":"### What is the bug?\n\n`http.request({ highWaterMark: N })` passes `N` to the TCP socket but does **not** set it on the `OutgoingMessage`'s internal `kHighWaterMark`. This causes two problems:\n\n1. **The user's `highWaterMark` is silently ignored for writes before the socket connects** (all Node versions). `write()` returns the wrong boolean because `_writeRaw` Path B checks `outputSize \u003c this[kHighWaterMark]` which remains at the default 64KB.\n\n2. **Deadlock on Node \u003e= 24.16.0** (post [#62936](https://github.com/nodejs/node/pull/62936)): Because `write()` incorrectly returns `false`, `kNeedDrain` is set. The stricter drain semantics from #62936 require the socket to emit `drain` — but the socket was never backpressured (the data is below the socket's HWM). Result: `drain` never fires, the function hangs forever.\n\n### Minimal reproduction\n\n```bash\n# Terminal 1 — start a simple server\nnode -e \"require('http').createServer((req, res) =\u003e { req.resume(); req.on('end', () =\u003e res.end('ok')); }).listen(9001)\"\n```\n\n```js\n// Terminal 2 — repro.js\nconst http = require('http');\n\nconst req = http.request({\n  hostname: '127.0.0.1',\n  port: 9001,\n  method: 'POST',\n  highWaterMark: 100_000,  // 100KB — should allow 64KB writes without backpressure\n});\n\nconst ok = req.write(Buffer.alloc(64 * 1024));\nconsole.log(`write() returned ${ok}, expected true (64KB \u003c 100KB highWaterMark)`);\n\nif (!ok) {\n  setTimeout(() =\u003e { console.error('DEADLOCK: drain never fired'); process.exit(1); }, 3000);\n  req.on('drain', () =\u003e { console.log('drain fired'); req.end(); });\n} else {\n  req.end();\n  req.on('response', (res) =\u003e { res.resume(); res.on('end', () =\u003e process.exit(0)); });\n}\n```\n\n### Results\n\n| Node version | `write()` returns | Drain fires? | Outcome |\n|---|---|---|---|\n| v22.22.2 | `false` (wrong, expected `true`) | Yes (old eager drain) | HWM ignored but no hang |\n| v26.5.0 | `false` (wrong, expected `true`) | Never | DEADLOCK |\n\n### Root cause\n\n`OutgoingMessage._writeRaw()` has two mutually exclusive paths:\n\n- **Path A** (socket connected): `conn.write(data)` — backpressure from socket's `writableHighWaterMark` (correct)\n- **Path B** (socket not yet connected): `outputSize \u003c this[kHighWaterMark]` — backpressure from OM's own property (incorrect, stuck at default)\n\nThe `OutgoingMessage` constructor already accepts `options.highWaterMark`:\n```js\n// lib/_http_outgoing.js\nthis[kHighWaterMark] = options?.highWaterMark ?? getDefaultHighWaterMark();\n```\n\nBut `ClientRequest` in `lib/_http_client.js` never passes the user's `highWaterMark` to the `OutgoingMessage` super constructor — it only passes it to `createConnection()` for the socket.\n\n### Expected behavior\n\n`write()` should return `true` when the written data is below the user-specified `highWaterMark`, regardless of whether the socket has connected yet.\n\n### Proposed fix\n\nPropagate the user's `highWaterMark` option to `OutgoingMessage` in the `ClientRequest` constructor so both write paths respect the same threshold.\n\nRefs: #62936, #39092, #32781","author":{"url":"https://github.com/trivenay","@type":"Person","name":"trivenay"},"datePublished":"2026-07-21T06:22:56.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/64645/node/issues/64645"}