Repository navigation
Conversation
|
Review requested:
|
|
Welcome to Node.js, and thank you for your first contribution! Before review, please take a moment to read:
Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal. |
|
Hello @nodejs/streams, I have implemented the fix and added a hardened regression test suite covering several edge cases. The PR is currently in |
1 similar comment
|
Hello @nodejs/streams, I have implemented the fix and added a hardened regression test suite covering several edge cases. The PR is currently in |
5f4ab6c to
526fd4e
Compare
526fd4e to
df3d6cc
Compare
|
Closing as a duplicate of #66243, which makes the same fix. Any additional regression coverage can be discussed there. |
Describe the bug
A regression was introduced in Node.js where
Duplex.from(async () => {})triggers an unhandledAbortError. This occurs because the async function resolves without consuming its input, and the implementation callsdestroyer(d), which synthesizes anAbortErrorfor any stream that is not yet finished.The Fix
I have replaced the call to
destroyer(d)withd.destroy()inlib/internal/streams/duplexify.js.Unlike
destroyer(),d.destroy()cleans up resources without synthesizing an artificial error. Since the async function resolved successfully, there is no actual error to report, and a duplex outside of a pipeline has no listeners for one.Testing done
I have implemented a hardened regression test suite in
test/parallel/test-duplex-from-hardened.jscovering:Duplex.from(async () => {})no longer throwsABORT_ERR.AbortError.stream.pipeline()'s destruction propagation.All tests pass on Node.js v22.23.3.
Fixes #66349