stream: fix writev unhandled rejection in fromWeb

[Han5991]

Summary

Fixes #62199

When using Duplex.fromWeb() or Writable.fromWeb() with cork()/uncork(), writes are batched into _writev(). If destroy() is called in the same microtask (after uncork()), the underlying WritableStream writer gets aborted, causing SafePromiseAll() to reject with a non-array value (e.g. an AbortError or null).

The done() callback in _writev() of both newStreamDuplexFromReadableWritablePair and newStreamWritableFromWritableStream unconditionally called error.filter(), assuming the value was always an array from SafePromiseAll. This caused a TypeError: Cannot read properties of null (reading 'filter') that became an unhandled rejection, crashing the process.

Root cause

done was used as both the resolve and reject handler for SafePromiseAll:

PromisePrototypeThen(SafePromiseAll(chunks, ...), done, done);

• Resolve path: done([undefined, undefined, ...]) — array, .filter() works
• Reject path: done(abortError) or done(null) — non-array, .filter() throws

Fix

Separate the resolve and reject handlers of SafePromiseAll. Promise.all resolving means all writes succeeded — there is no error to report. Promise.all rejecting passes a single error value directly.

PromisePrototypeThen(SafePromiseAll(chunks, ...), () => done(), done);

• () => done() — resolve path: all writes succeeded, call callback with no error
• done — reject path: single error passed directly to callback

The same fix is applied to both newStreamDuplexFromReadableWritablePair and newStreamWritableFromWritableStream.

Test

Added test/parallel/test-webstreams-duplex-fromweb-writev-unhandled-rejection.js with the exact reproduction from the issue report (cork → write → write → uncork → destroy).

[Renegade334]

#62291 is already open (although I believe the approach here is the correct one)

[Han5991]

Agreed — and since #62291 is already open, I've opened this as a separate issue because I believe the approach here is the correct one. @Renegade334

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.71%. Comparing base (bf1aebc) to head (5df0476).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62297      +/-   ##
==========================================
- Coverage   89.72%   89.71%   -0.01%     
==========================================
  Files         695      695              
  Lines      214464   214462       -2     
  Branches    41067    41059       -8     
==========================================
- Hits       192420   192410      -10     
  Misses      14106    14106              
- Partials     7938     7946       +8     

Files with missing lines	Coverage Δ
lib/internal/webstreams/adapters.js	86.60% <100.00%> (+0.15%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Han5991]

@Renegade334

Could you possibly review this PR once again? I am aware that there is a previous PR, but it seems quite some time has passed.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/72520/

[Han5991]

@Renegade334

#62297 Jenkins failures appear unrelated to this PR.

The failing test across platforms is test-inspector-dom-storage, and the stack trace points to node:internal/inspector/webstorage / node:inspector, not lib/internal/webstreams/adapters.js. The failure matches a separate main regression introduced by d93935b (inspector: auto collect webstorage data, PR #62145), where DOMStorage events were emitted without coercing key/value to strings. That regression was then fixed by 449a93a (inspector: coerce key and value to string in webstorage events, PR #62616).

This Jenkins run appears to have picked up the broken main state before the follow-up fix landed, rather than a problem caused by #62297. Could CI be re-run on the current base?