Settle a TS compression write or close cut short by a cancel

[jasnell]

Under TS a compression pair moves its output into the readable inside
the write or close that produced it, in 64 KiB pieces. Resolving a
waiting read looks up then on its result, so an Object.prototype.then
getter can cancel the reader in the middle of that drain. The drain then
stopped, and the write or close rejected with the cancel reason. With a
gzip pair, a pending read and an Object.prototype.then getter that
cancels the reader, TS / C++ / Node:

write: rejected with the reason / resolved / resolved
close: rejected with the reason / resolved / rejected

A spec TransformStream whose transform or flush enqueues the same output
resolves both. After a cancel during the transform the writable errors
with the reason; after one during the flush, close, writer.closed and
the cancel all resolve. That is what TS's own TransformStream and Node's
do. Node's compression streams are a zlib Duplex adapter, not a
TransformStream.

How a transform splits its output into chunks is implementation-defined,
so a drain cut short now settles as a transform that enqueued all its
output as one chunk before the cancel: the rest is dropped and the write
resolves, after which the writable is errored as before (compression
ledger #13). The close resolves too, as do writer.closed and the
cancel; for the close this is parity with C++. A readable errored during
the drain (the Node.js interop hook) still rejects the close with its
error, as the spec's flush does.

Pins: compression reentrancy.js cancelFromReadResultThenGetterDuringWrite
now expects the write to resolve in both implementations (TS: the
writable errors with the reason; C++: untouched);
cancelFromReadResultThenGetterDuringClose (parity: close, writer.closed
and the cancel resolve, the read the getter fired on still gets the
tail); interopErrorFromReadResultThenGetterDuringClose (TS only: the
close rejects with the hook's error). Without the source change, the
first two fail, in the TS cells only; the third passes either way and
guards the errored-readable branch.

[ask-bonk]

@jasnell Bonk workflow failed. Check the logs for details.

View workflow run · To retry, trigger Bonk again.

[ask-bonk]

Since last review: 1 resolved, 0 still open, 0 new.
LGTM!

Not re-run: api-compat, docs, compat-flags, design-simplicity (no author changes in their files since the last review)

---

_{Reviewed commit: 348d9ecc · github run}

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 38.60%. Comparing base (4018249) to head (348d9ec).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7645   +/-   ##
=======================================
  Coverage   38.59%   38.60%           
=======================================
  Files         868      868           
  Lines      268583   268608   +25     
  Branches    25422    25426    +4     
=======================================
+ Hits       103665   103687   +22     
  Misses     150704   150704           
- Partials    14214    14217    +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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.