stream: preserve mutable chunks in Web Stream adapters

[seungwoo505]

When a Node.js writable is converted with Writable.toWeb(), the Web Streams
write() promise can currently settle as soon as the native write() call
returns true. That return value only represents backpressure, so the native
stream may still retain the supplied mutable BufferSource. Reusing the buffer
after awaiting the Web write can therefore change bytes that have not yet been
consumed.

This change:

• waits for the native per-write callback when the stream is an uncorked,
  unmodified Writable;
• coordinates callback completion with drain, aborts, and native stream
  errors;
• passes a private same-brand BufferSource copy for Duplex, corked, overridden,
  and legacy write paths where waiting for a callback would change existing
  completion behavior;
• preserves HTTP input validation before fallback copies; and
• preserves SharedArrayBuffer backing for cloned views.

The original native Writable.prototype.write and
OutgoingMessage.prototype.write methods are captured so patched methods and
accessors are classified and invoked consistently.

Validation included:

• make -j4 test (full test suite passed)
• the changed Web Streams adapter, Duplex, and compression tests
• the existing Writable, Duplex, and Web Streams adapter test set
• CompressionStream WPT tests
• repeated async regression tests
• ESLint and git diff --check

Fixes: #64549

[nodejs-github-bot]

Review requested:

• @nodejs/http
• @nodejs/net
• @nodejs/streams

[bjohansebas]

why expose this?

[seungwoo505]

The Web Streams adapter uses this export to compare the active write() method with the original OutgoingMessage.prototype.write.
This distinction preserves the native validation behavior without applying it to overridden write() implementations.
The reference is captured here so a later prototype monkey-patch is not mistaken for the original method.

[seungwoo505]

Hi @bjohansebas, just a friendly follow-up on this.
I’ve answered the question above and rebased the PR onto the latest main, resolving the merge conflict.
The build, relevant Web Streams tests, and ESLint all pass locally.
When you have time, could you please take another look?
Thank you!

[mcollina]

Sorry for the radio silence. Can you rebase again?

[seungwoo505]

Sorry, I just saw your message.
I’ll rebase it by the end of today

[seungwoo505]

Hi @mcollina, I’ve rebased the PR onto the latest main and resolved the conflicts.
git diff --check, make -j4, make test, the relevant Web Streams tests, and the targeted JavaScript lint checks all pass locally.
Could you please take a look when you have a chance?
Thanks!

[mcollina]

lgtm

[github-actions]

Benchmark GHA (webstreams / adapters): https://github.com/nodejs/node/actions/runs/36556500893

Results

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

Benchmark results:

                                                         confidence improvement accuracy (*)    (**)   (***)
webstreams/adapters.js kind='readable-from-web' n=100000                 1.94 %       ±8.32% ±10.97% ±14.07%
webstreams/adapters.js kind='readable-to-web' n=100000                   1.36 %       ±8.69% ±11.46% ±14.70%
webstreams/adapters.js kind='writable-from-web' n=100000                -0.54 %       ±7.68% ±10.13% ±13.00%
webstreams/adapters.js kind='writable-to-web' n=100000          ***    -81.09 %       ±6.21%  ±8.21% ±10.57%

Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 4 comparisons, you can thus
expect the following amount of false-positive results:
  0.20 false positives, when considering a   5% risk acceptance (*, **, ***),
  0.04 false positives, when considering a   1% risk acceptance (**, ***),
  0.00 false positives, when considering a 0.1% risk acceptance (***)

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

[nodejs-github-bot]

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

[panva]

The benchmark shows a significant drop for writable-to-web. I think this needs some work before landing.

[seungwoo505]

I’ve confirmed the performance regression shown in the benchmark.
I’ll work on addressing it as soon as possible.

[codecov]

Codecov Report

❌ Patch coverage is 90.71207% with 30 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.36%. Comparing base (75e4bbe) to head (3c2a3c3).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/webstreams/adapters.js	90.35%	29 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #64579      +/-   ##
==========================================
- Coverage   90.36%   90.36%   -0.01%     
==========================================
  Files         792      792              
  Lines      275398   275793     +395     
  Branches    52776    52852      +76     
==========================================
+ Hits       248877   249210     +333     
- Misses      16937    17005      +68     
+ Partials     9584     9578       -6     

Files with missing lines	Coverage Δ
lib/internal/streams/writable.js	96.44% <100.00%> (+0.01%)	⬆️
lib/internal/webstreams/writablestream.js	99.52% <100.00%> (+<0.01%)	⬆️
lib/internal/webstreams/adapters.js	88.53% <90.35%> (+0.29%)	⬆️

... and 40 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.