René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"req.signal.aborted becomes true after request body parse / stream close in Node 24.18.0","articleBody":"### Version\n\nv24.18.0\n\n### Platform\n\n```text\nDarwin Deniss-MacBook-Pro.local 25.5.0 Darwin Kernel Version 25.5.0: Mon Apr 27 20:41:19 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T8122 arm64\n```\n\n### Subsystem\n\n_No response_\n\n### What steps will reproduce the bug?\n\nIn Node 24.18.0, `IncomingMessage.prototype.signal.aborted` becomes true after the incoming message body has finished parsing and the request stream closes, even though `req.aborted === false`. This makes `req.signal.aborted` unreliable for detecting actual client aborts.\n\n**Context**\n\n- Node version: v24.18.0\n- Environment: local dev, no reverse proxy\n- Framework: Express + body-parser\n- Route: PATCH /tables/1\n- Comparison: a separate GET route does not show the issue\n\n**Suggested reproduction steps**\n\n1. Start an Express server on Node 24.18.0\n2. Add middleware logging:\n- `req.aborted`\n- `req.complete`\n- `req.signal.aborted`\n- `req.socket.destroyed`\n3. Send a PATCH request with a JSON body\n4. Observe:\n- early middleware logs `signalAborted: false`\n- later the same request logs `signal.aborted: true`\n- `req.close `fires before `signal.aborted` becomes true\n\nCode to reproduce:\n```\n\n// repro.js\nimport express from \"express\";\nimport bodyParser from \"body-parser\";\n\nconst app = express();\napp.use(bodyParser.json());\n\napp.use((req, res, next) => {\n\tconsole.log(\"early middleware:\", {\n\t\turl: req.originalUrl,\n\t\tmethod: req.method,\n\t\taborted: req.aborted,\n\t\tcomplete: req.complete,\n\t\tsignalAborted: req.signal.aborted\n\t});\n\n\treq.once(\"close\", () => {\n\t\tconsole.log(\"req close event\", req.originalUrl, {\n\t\t\taborted: req.aborted,\n\t\t\tsignalAborted: req.signal.aborted\n\t\t});\n\t});\n\n\tnext();\n});\n\napp.patch(\"/tables/1\", async (req, res) => {\n\tconsole.log(\"route start:\", {\n\t\taborted: req.aborted,\n\t\tsignalAborted: req.signal.aborted\n\t});\n\n\tawait new Promise((resolve) => setTimeout(resolve, 200));\n\n\tconsole.log(\"route before res send\", {\n\t\taborted: req.aborted,\n\t\tsignalAborted: req.signal.aborted\n\t});\n\n\tres.json({ ok: true });\n});\n\napp.listen(3009, () => {\n\tconsole.log(\"listening on 3009\");\n});\n\n```\n\n### How often does it reproduce? Is there a required condition?\n\nReproduces with PATCH requests that have a JSON body.\n\n### What is the expected behavior? Why is that the expected behavior?\n\n`req.signal.aborted` should only become `true` when the client aborts the request (transport-level cancellation before or during request processing), not when the incoming message handling completes normally or when body parsing ends.\n\n### What do you see instead?\n\nFor a normal PATCH request with a body:\n\n- early request logs show `signalAborted: false`\n- request body parsing completes successfully\n- `req.close` triggers\n- later, `req.signal.aborted` becomes true\n- `req.aborted` remains false\n\nKey evidence\n\n- `req.close` event in route handler is logged before the route observes `signal.aborted === true`\n- `req.aborted` remains `false`\n- normal cURL request reproduces it\n- the same request type in a different route does not reproduce it\n\nThis means the new signal.aborted property is firing on request stream completion/closure rather than on genuine abort.\n\n### Additional information\n\n**Why this is a bug**\n\nThe new `req.signal `API is supposed to expose request cancellation state. If it becomes true after normal request completion or stream close, it is effectively useless for distinguishing real client aborts. This appears to be the Node HTTP internals abort signal being fired when the request handling completes, rather than when the client actually aborts. That behavior breaks the use case of `req.signal.aborted` for client abort detection.","author":{"url":"https://github.com/dnorrstrand","@type":"Person","name":"dnorrstrand"},"datePublished":"2026-07-09T11:37:53Z","url":"https://github.com/nodejs/node/issues/64390"}