[mcollina]

Since #65548, Writable.fromWeb() and Duplex.fromWeb() dispatch writes to the WritableStream directly and complete them through a shared write tracker instead of writer.ready + writer.write() promises. That changed the async context in two cases:

• A write issued before the WritableStream has started is queued and processed from its start step, so the sink runs in the context of the code that created the WritableStream:

  const ws = als.run('creator', () => new WritableStream({ write() { console.log(als.getStore()); } }));
  const writable = Writable.fromWeb(ws);
  als.run('request', () => writable.write('a'));
  // main: 'creator'; v24.18 / v26.5 and this PR: 'request'

• The tracker invokes the Node.js write callback synchronously from whatever context completed the sink write, so the writes and final() it releases run there as well (e.g. after a write queued during an async start()).

This restores the previous behavior without touching the steady-state path:

• writes issued before the start are dispatched from a writer.ready reaction, as the promise-based adapter did. They fail through the tracker if the stream was closed or errored meanwhile (destroy() during start, covered by test-webstreams-duplex-fromweb-writev-unhandled-rejection.js);
• the tracker captures the async context frame at dispatch and delivers the callback in it. When it completes in the same context, which is always the case without AsyncLocalStorage and after the start, it stays synchronous. Otherwise it is delivered from a reaction registered in that context.

The new test covers write(), corked writev(), an async start(), Duplex.fromWeb(), and writes after the start. Expectations match v24.18.0 (with and without --no-async-context-frame) and v26.5.1; four of the five cases fail on main.

Benchmarks (adapters, encoding-streams, js_transfer; 30 runs): no significant change (writable-from-web +0.7% / -1.1% over two runs).

#65548 is in v26.10.0 and on v24.x-staging, so this should follow it to both lines.

While working on this I found a separate, pre-existing bug, also present in v26.5.1: writer.write() after writer.close() while the close is in flight hits an internal assertion in writableStreamDefaultControllerGetChunkSize instead of rejecting. Not addressed here.

Refs: #66906
Refs: #65548
Refs: #67052
Refs: #67054

🤖 Generated with Claude Code

https://claude.ai/code/session_01Sfj4nCwaLmXB1NxA7sEJfi

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.65%. Comparing base (29bd740) to head (72bef1e).
⚠️ Report is 214 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #67055      +/-   ##
==========================================
+ Coverage   90.47%   90.65%   +0.17%     
==========================================
  Files         791      797       +6     
  Lines      277245   278353    +1108     
  Branches    53310    53529     +219     
==========================================
+ Hits       250834   252329    +1495     
+ Misses      16811    16401     -410     
- Partials     9600     9623      +23     

Files with missing lines	Coverage Δ
lib/internal/webstreams/adapters.js	88.05% <100.00%> (-0.19%)	⬇️
lib/internal/webstreams/writablestream.js	99.53% <100.00%> (+0.01%)	⬆️

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