René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"stream/iter: pull() swallows abort when async transform flush resolves to null","articleBody":"### Version\n\nmain\n\n### Platform\n\n```text\nN/A\n```\n\n### Subsystem\n\nstream\n\n### What steps will reproduce the bug?\n\n```js\nimport { pull, text } from 'node:stream/iter';\n\nconst controller = new AbortController();\nconst reason = new Error('boom');\n\nconst transform = async (chunks) => {\n  if (chunks !== null) return chunks;\n\n  controller.abort(reason);\n  return null;\n};\n\ntext(pull('x', transform, { signal: controller.signal })).then(\n  (value) => console.log('fulfilled:', JSON.stringify(value)),\n  (error) => console.log('rejected:', error === reason, error),\n);\n```\n\n### How often does it reproduce? Is there a required condition?\n\nAlways\n\n### What is the expected behavior? Why is that the expected behavior?\n\n```console\nrejected: true Error: boom\n```\n\nThe pipeline should reject with `reason`, making `error === reason` true. An abort during transform flushing should not be converted into normal iterator completion.\n\nFrom [§9.1, `Stream.pull()`, steps 5–7](https://iter-streams.proposal.wintertc.org/#pull-method):\n> If signal is not undefined, set pipelineController’s signal to follow signal.\n\n### What do you see instead?\n\n```console\nfulfilled: \"x\"\n```\n\nThe pipeline fulfills successfully with `\"x\"`, even though its signal was aborted while the asynchronous flush was completing. The abort reason is never delivered to the consumer.\n\n### Additional information\n\n_No response_","author":{"url":"https://github.com/trivikr","@type":"Person","name":"trivikr"},"datePublished":"2026-08-17T05:20:59Z","url":"https://github.com/nodejs/node/issues/65345"}