Buffer the compression stage's output in blocks released as they are …

[jasnell]

compression.ts drained the codec's entire output into the readable after every write as one Uint8Array, so each write's output was held twice at its peak (C++ stage buffer + JS copy), and chunks were unbounded. The shared C++ CodecStage also kept its output in a doubling kj::Vector that never released capacity. Reproduced at 79bfba9: a 16 MiB member came out as one chunk (through tee, pipeThrough, bodies); 256 MiB peaked at 661 MiB RSS (C++ 462).

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

Bounds compression-stream output delivery and releases codec buffers incrementally.

1. High: Added an inline suggestion to compatibility-gate the observable default-read chunking change.

github run

[codecov-commenter]

Codecov Report

❌ Patch coverage is 78.14570% with 33 lines in your changes missing coverage. Please review.
✅ Project coverage is 37.54%. Comparing base (5adb86c) to head (cc10f59).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/workerd/api/compression-test.c++	77.10%	4 Missing and 15 partials ⚠️
src/workerd/util/ring-buffer-test.c++	60.00%	0 Missing and 12 partials ⚠️
src/workerd/api/compression.c++	96.15%	0 Missing and 1 partial ⚠️
src/workerd/util/ring-buffer.h	87.50%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7425      +/-   ##
==========================================
+ Coverage   37.52%   37.54%   +0.02%     
==========================================
  Files         836      837       +1     
  Lines      258430   258549     +119     
  Branches    23747    23785      +38     
==========================================
+ Hits        96963    97084     +121     
+ Misses     148229   148203      -26     
- Partials    13238    13262      +24     

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

[guybedford]

Reviewed this layer (ts-streams-body-consumption-oom...ts-streams-decompression-delivery). Ran the compression suite (all variants) plus the new kj_test locally, all green, and probed the delivery state machine with a few extra cases (stale demandUnmet after releaseLock, BYOB min across writes, two BYOB reads pending at close, slow reader over many small writes) - no loss, duplication or ordering issues. The pull-driven delivery, BYOB fill-in-place and bounded default pieces all look right.

One design concern with where the bytes wait, detailed inline on compression.c++: this layer moves the readable's write-ahead backlog out of ArrayBuffer backing stores (inside the V8 sandbox, accounted as external memory) into plain C++ heap. The delivery mechanics can stay as they are; the storage should stay in the sandbox. The remaining comments are nits.

[npaun]

My clanker review found something but this too esoteric for me to assess; lmk if this is plausible:

The new loop assumes that the readable cannot become canceled or errored between successive enqueues. That assumption is false in the actual stream implementation:

1. byteControllerEnqueue() synchronously notifies the queue’s cursors.
2. QueueCursor.notify() resolves a pending read (

   workerd/src/per_isolate/webstreams/queue.ts

   Lines 770 to 790 in cc10f59

   	// Called by the queue when new data (or the close sentinel) is enqueued.
   	notify(): void {
   	while (this.#pendingReads.length > 0) {
   	const slot = this.#queue.getEntry(this.#position);
   	if (slot === undefined) break;
   	if (slot === CLOSE_SENTINEL) {
   	// End of stream: every remaining pending read resolves done. This
   	// deliberately uses the non-virtual helper — the byte cursor's
   	// pending pull-intos must NOT be auto-committed at the sentinel
   	// (see "Close semantics for byte cursors" in the design doc).
   	this.#resolvePendingReadsAsDone();
   	break;
   	}
   	const entry = slot as QueueEntry<T>;
   	const value = this.readEntryValue(entry);
   	this.advancePastEntry();
   	// assert: pendingReads is non-empty (the while condition guarantees it)
   	const pending = this.#pendingReads.shift() as PendingRead<V>;
   	pending.resolve(createReadResult(value, false));
   	}
   	this.#queue.onCursorAdvanced();

   ) with an ordinary { value, done } object.
3. Promise resolution synchronously looks up that object’s then property. An Object.prototype.then getter can call reader.cancel().
4. Cancellation marks the controller done and invokes the compression pair’s cancel callback.
5. drainStage() continues, pulls another piece, then attempts to enqueue into the canceled readable. That enqueue throws.
   For output larger than the pieces already pulled, the remainder stays in the native stage. The cancel callback only clears input snapshots and errors the writable; the JS codec interface has no clear() operation. The in-flight write also receives an incidental enqueue TypeError. If this happens inside failCodec(), it skips failBoth(e) and replaces the original codec exception.
   This is a specific reentrancy edge, not ordinary cancellation from a promise continuation. The repository already explicitly recognizes read-result then-getter reentrancy.

[npaun]

If there are lots of very tiny writes this could be inefficient. Clanker makes a big deal of this, but I suspect it's not worth trying to optimize for this.