Skip to content

stream: prevent AbortError when Duplex.from resolves without consuming input (#66349) - #66958

Closed
OMD-123 wants to merge 1 commit into
nodejs:mainfrom
OMD-123:fix/duplex-from-hardened
Closed

OMD-123 wants to merge 1 commit into
nodejs:mainfrom
OMD-123:fix/duplex-from-hardened

Conversation

@OMD-123

@OMD-123 OMD-123 commented Oct 23, 2026

Copy link
Copy Markdown

Describe the bug

A regression was introduced in Node.js where Duplex.from(async () => {}) triggers an unhandled AbortError. This occurs because the async function resolves without consuming its input, and the implementation calls destroyer(d), which synthesizes an AbortError for any stream that is not yet finished.

The Fix

I have replaced the call to destroyer(d) with d.destroy() in lib/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.js covering:

  • Basic Regression: Verified that Duplex.from(async () => {}) no longer throws ABORT_ERR.
  • Partial Consumption: Verified that partial consumption of input also resolves cleanly.
  • Error Fidelity: Confirmed that if the async function throws its own error, that error is propagated correctly and not masked by an AbortError.
  • Pipeline Integration: Verified that the fix does not break stream.pipeline()'s destruction propagation.

All tests pass on Node.js v22.23.3.

Fixes #66349

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/streams

@nodejs-github-bot nodejs-github-bot added needs-ci PRs that need a full CI run. stream Issues and PRs related to Node.js streams. labels Oct 23, 2026
@github-actions

Copy link
Copy Markdown
Contributor

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.

@OMD-123

OMD-123 commented Oct 23, 2026

Copy link
Copy Markdown
Author

Hello @nodejs/streams, I have implemented the fix and added a hardened regression test suite covering several edge cases. The PR is currently in needs-ci state; I would appreciate it if a triager could trigger the CI run. Thank you!

1 similar comment
@OMD-123

OMD-123 commented Oct 23, 2026

Copy link
Copy Markdown
Author

Hello @nodejs/streams, I have implemented the fix and added a hardened regression test suite covering several edge cases. The PR is currently in needs-ci state; I would appreciate it if a triager could trigger the CI run. Thank you!

@OMD-123
OMD-123 force-pushed the fix/duplex-from-hardened branch 3 times, most recently from 5f4ab6c to 526fd4e Compare October 23, 2026 14:03
@OMD-123
OMD-123 force-pushed the fix/duplex-from-hardened branch from 526fd4e to df3d6cc Compare October 23, 2026 14:10
@inoway46

Copy link
Copy Markdown
Contributor

Closing as a duplicate of #66243, which makes the same fix. Any additional regression coverage can be discussed there.

@inoway46 inoway46 closed this Oct 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-ci PRs that need a full CI run. stream Issues and PRs related to Node.js streams.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

stream: Duplex.from errors when async function body resolves without consuming its input

3 participants