René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Close listener leak in fs/promises `createReadStream`","articleBody":"### Version\n\nv24.18.0\n\n### Platform\n\n```text\nDarwin *.local 24.6.0 Darwin Kernel Version 24.6.0: Tue Apr 21 20:19:12 PDT 2026; root:xnu-11417.140.69.710.16~1/RELEASE_ARM64_T6041 arm64\n```\n\n### Subsystem\n\nfs/promises\n\n### What steps will reproduce the bug?\n\nHere is a silly example which prints the first 11 bytes of a file by reading them separately from disk:\n\n```js\nimport { buffer } from 'node:stream/consumers';\nimport { open } from 'node:fs/promises';\n\nconst f = await open('my-file.txt');\nfor (let i = 0; i \u003c 11; i++) {\n  const byte = await buffer(f.createReadStream({ start: i, end: i, autoClose: false }));\n  console.log(`byte ${i} is ${byte[0]}. Close listeners = ${f.listeners('close').length}`);\n}\n```\n\nRunning it (pointing at any file containing at least 11 bytes) will demonstrate the issue (output below)\n\n### How often does it reproduce? Is there a required condition?\n\nEvery call to `createReadStream` [adds a close listener to the file handle](https://github.com/nodejs/node/blob/f2f241a40ffca9ec72a103842a5e52c0c4f52767/lib/internal/fs/streams.js#L155), and I have not found a way to remove this listener. If called at least 11 times, it will trigger Node.js' built-in event leak detection warning. The threshold can be increased to avoid this warning, but the leak remains.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nOnce a stream is consumed, the [`close` event listener it attaches to the `FileHandle`](https://github.com/nodejs/node/blob/f2f241a40ffca9ec72a103842a5e52c0c4f52767/lib/internal/fs/streams.js#L155) should be removed, even when `autoClose` is false, so that applications can read arbitrarily many ranges from a file.\n\n### What do you see instead?\n\n> ```\n> byte 0 is 0. Close listeners = 1\n> byte 1 is 0. Close listeners = 2\n> byte 2 is 0. Close listeners = 3\n> byte 3 is 0. Close listeners = 4\n> byte 4 is 0. Close listeners = 5\n> byte 5 is 0. Close listeners = 6\n> byte 6 is 0. Close listeners = 7\n> byte 7 is 0. Close listeners = 8\n> byte 8 is 0. Close listeners = 9\n> byte 9 is 0. Close listeners = 10\n> (node:70360) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added to [FileHandle]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit\n>     at genericNodeError (node:internal/errors:985:15)\n>     at wrappedFn (node:internal/errors:539:14)\n>     at _addListener (node:events:590:17)\n>     at FileHandle.addListener (node:events:608:10)\n>     at importFd (node:internal/fs/streams:156:16)\n>     at new ReadStream (node:internal/fs/streams:189:30)\n>     at FileHandle.createReadStream (node:internal/fs/promises:363:12)\n>     at file:///[...]/test.mts:6:15\n>     at process.processTicksAndRejections (node:internal/process/task_queues:104:5)\n> byte 10 is 0. Close listeners = 11\n> ```\n\n### Additional information\n\nThis can be worked around in user-space with a hacky approach:\n\n```js\nfunction createSafeReadStream(handle, options) {\n  const before = handle.listeners('close').length;\n  const stream = handle.createReadStream(options);\n  const after = handle.listeners('close');\n  if (after.length > before) {\n    const listener = after[after.length - 1];\n    const teardown = () => {\n      handle.off('close', listener);\n      stream.off('end', teardown);\n      stream.off('error', teardown);\n    };\n    stream.once('end', teardown);\n    stream.once('error', teardown);\n  }\n  return stream;\n}\n\n// ...\n\nfor (let i = 0; i \u003c 11; i++) {\n  const byte = await buffer(createSafeReadStream(f, { start: i, end: i, autoClose: false }));\n  console.log(`byte ${i} is ${byte[0]}. Close listeners = ${f.listeners('close').length}`);\n}\n```","author":{"url":"https://github.com/davidje13","@type":"Person","name":"davidje13"},"datePublished":"2026-06-30T10:17:10Z","url":"https://github.com/nodejs/node/issues/64214"}