node:zlib: refuse reset() of a zstd frame that is open and has given output by robobun · Pull Request #47376 · oven-sh/bun

robobun · 2026-10-29T14:16:39Z

Draft, on top of #47079: the zstd half of #47364. @dylan-conway: take this commit into #47079, or I retarget it to main after #47079 lands.

Problem

reset() on a ZstdCompress stream that has given part of a frame returns with no error, and the output fails to decode (ZSTD_error_corruption_detected). No user reported it.
Node.js v26.11.0 and later report ERR_ZLIB_INCOMPLETE_FRAME and destroy the stream (zlib: reject reset while a zstd frame is incomplete nodejs/node#66088). Context::reset (src/runtime/node/zlib/NativeZstd.rs:447 on Replace the zstd C library with a port to safe Rust #47079) makes a new context with no check.

Fix

The zstd Context records that the open frame has given output. Context::reset returns Node's error before it makes a new context. The existing onerror path destroys the stream.
Verified on a debug build: test/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts (main fails 8 of 14, Node.js v26.12.1 passes all) and Node's test-zlib-zstd-reset-incomplete-frame.js, unmodified. Also 8 test-zlib-zstd*.js files.
Self-reviewed with node:zlib: refuse reset() of a gzip member that is open and has given output #47364. That review asked for this separate PR.

Background

A zstd frame puts out its header at the first flush. A new context never writes its end.
Context is the codec state behind the native handle (_handle) of one stream. do_work runs once per native write.

Downsides

Write, flush, reset() per segment on one ZstdCompress stream now destroys the stream. With no 'error' listener the process exits.
A ZstdCompress native write runs two more compares and one store in do_work. Not measured on the port. On the C library: 29 → 34 or 35 instructions.
An accepted reset() still drops the parameters and the dictionary (node:zlib: reset a zstd stream in place, keep its dictionary and parameters #44261). A later reset() can then differ from Node.js (see Notes).

Notes

What each runtime does

hello is written first, and world is written with end() if the stream is still open. "main" is da867c6. Context::reset of #47079 has no check either.

stream	steps	main	this PR	Node.js v26.12.1
`createZstdCompress()`	write, `reset()`	`world`	`world`	`world`
`createZstdCompress()`	write, flush, `reset()`	no error, `ZSTD_error_corruption_detected`	`'error'` `ERR_ZLIB_INCOMPLETE_FRAME`, destroyed	the same
`createZstdCompress()`	512 KiB write, `reset()`	no error, `ZSTD_error_corruption_detected`	`ERR_ZLIB_INCOMPLETE_FRAME`	the same
`createZstdCompress()`	write, flush(`ZSTD_e_end`), `reset()`	`helloworld`	`helloworld`	`helloworld`
ZstdCompress `_handle`	`writeSync(flush)`, `reset()`	returns	`onerror(message, 60, "ERR_ZLIB_INCOMPLETE_FRAME")`	the same
`createZstdDecompress()`	half of the input, `reset()`, all of the input	decodes	the same	the same

The error

Error, code ERR_ZLIB_INCOMPLETE_FRAME, errno 60 (ZSTD_error_stage_wrong), message "Cannot reset a zstd stream with an incomplete frame; end the frame or discard the output produced so far".
The native handle gives the three values to onerror, as Node.js does. The code is not in Node's lib/internal/errors.js, so there is no ErrorCode.ts entry.
A refused reset() does not change the codec. The frame can still be finished, and it decodes.

Source: ZstdCompressContext::ResetStream.

One flag where Node.js has two

Node.js keeps frame_complete_ and frame_output_emitted_, and refuses if !frame_complete_ && frame_output_emitted_. The code sets frame_complete_ only where it clears frame_output_emitted_. So the two are never both true, and the test is the same as frame_output_emitted_.

The flag is updated one time after the compress loop of do_work, from the position of the output buffer.

Tests

test/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts uses node:test and node:assert. The same file passes under Node.js v26.12.1 (node --test, 14 pass). A debug build of this branch: 14 pass. A release build of main (da867c6): 8 fail, 6 pass.
test-zlib-zstd-reset-incomplete-frame.js in test/js/node/test/parallel/ is the file of Node.js v26.12.1, byte for byte. main fails 2 of 5. This branch passes 5.
Both files pass on the debug ASAN build with the environment of the ASAN lane (detect_leaks=1, BUN_DESTRUCT_VM_ON_EXIT=1, BUN_JSC_validateExceptionChecks=1).
Also run on the debug build of this branch: 63 test-zlib*.js, 6 test-stream-iter-transform*.js and 3 test-webstreams-*compression*.js vendored files, zlib-handle-bounds-check.test.ts (41 pass, with its zstd workers case), zlib-reset-race.test.ts, zlib-onerror-reentrancy.test.ts, zlib-estimated-size-gc.test.ts, zlib.test.js (473 pass), test/js/bun/util/zstd.test.ts (253 pass) and test/js/web/streams/compression.test.ts (74 pass).
Not done on the port: the check that each clause has a failing test, and the release measurements. Both were done for the same lines on the C library before node:zlib: refuse reset() of a gzip member that is open and has given output #47364 was split (each of 7 clause deletions failed a test, and do_work went from 29 to 34 or 35 instructions per write). I repeat them when this PR targets main.
Not run: Windows and macOS.

After an accepted `reset()`

Context::reset still makes a new context, as Node.js did before v26.10.0. So an accepted reset() drops the parameters and the dictionary. #44261 changes that. Until then, the check can give a different answer from Node.js for the frame after an accepted reset(). A probe of 7 handle sequences differs in 3:

stream options	after one accepted `reset()`	this PR	Node.js v26.12.1
`ZSTD_c_checksumFlag`	`ZSTD_e_end` into a buffer 4 bytes short of the frame, `reset()`	accepted (no checksum any more, the frame fits)	refused
`ZSTD_c_windowLog` 10	an 8 KiB write with no flush, `reset()`	accepted (0 bytes out)	refused (246 bytes out)
a dictionary	`ZSTD_e_end` into a buffer of the size of the first frame, `reset()`	refused (no dictionary any more, the frame is longer)	accepted

The two control rows with no reset() before them agree with Node.js.

Rows that still differ from Node.js

The rows above.
A closed native handle: _handle.writeSync(flush), _handle.close(), _handle.reset(). Node.js calls onerror with errno 60, because its flags outlive Close(). Bun returns for each closed handle (node_zlib_binding.rs). The stream API cannot reach this state.
reset() of a destroyed stream. node:zlib: refuse reset() of a gzip member that is open and has given output #47364 changes it to ERR_INTERNAL_ASSERTION, as in Node.js. This PR does not.

[human-review] gate passed · iteration 1 · 3 files touched

fails on main (without fix)

ASAN without fix: 8 FAILED
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts
bun test v1.4.4 (367d939d9)

test/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts:
76 |     stream.write("hello");
77 |     await flushed(stream);
78 |     assert.ok(Buffer.concat(chunks).length > 0);
79 | 
80 |     assert.strictEqual(stream.reset(), undefined);
81 |     assert.strictEqual(stream.destroyed, true);
                ^
AssertionError: Expected values to be strictly equal:

false !== true

 generatedMessage: true,
     actual: false,
   expected: true,
   operator: "strictEqual",
       diff: "simple",
       code: "ERR_ASSERTION"

      at /workspace/bun/test/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts:81:12
      at node:test:1781:26
      at executeTestNode (node:test:1785:63)
      at processTicksAndRejections (native:35:14)
(fail) ZstdCompress: reset() in an open frame > after a flush, destroys the stream before it returns [243.34ms]
92 |     // This write stays in the compressor. The frame is still open, and part of it is out.
93 |     await wri
... (truncated)

release without fix: 8 FAILED
bun test v1.4.3-canary.1 (367d939d9)

test/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts:
76 |     stream.write("hello");
77 |     await flushed(stream);
78 |     assert.ok(Buffer.concat(chunks).length > 0);
79 | 
80 |     assert.strictEqual(stream.reset(), undefined);
81 |     assert.strictEqual(stream.destroyed, true);
                ^
AssertionError: Expected values to be strictly equal:

false !== true

 generatedMessage: true,
     actual: false,
   expected: true,
   operator: "strictEqual",
       diff: "simple",
       code: "ERR_ASSERTION"

      at /workspace/bun/test/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts:81:12
      at node:test:1445:26
      at executeTestNode (node:test:1448:63)
      at processTicksAndRejections (native:7:39)
(fail) ZstdCompress: reset() in an open frame > after a flush, destroys the stream before it returns [10.81ms]
92 |     // This write stays in the compressor. The frame is still open, and part of it is out.
93 |     await written(stream, "world");
94 |     assert.strictEqual(Buffer.concat(chunks).length, given);
95 | 
96 |     stream.reset();
97 |     assert.strictEqual(stream.destroyed, true);
           
... (truncated)

passes on PR (with fix)

ASAN with fix: all passed
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts
bun test v1.4.4 (367d939d9)

test/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts:
(pass) ZstdCompress: reset() in an open frame > after a flush, destroys the stream before it returns [289.10ms]
(pass) ZstdCompress: reset() in an open frame > after output and then a write that gives none [33.80ms]
(pass) ZstdCompress: reset() in an open frame > is allowed once a finish flush completed it, and the next one is guarded again [36.00ms]
(pass) ZstdCompress: reset() in an open frame > inside a 'data' listener [29.06ms]
(pass) ZstdCompress: reset() in an open frame > after a synchronous _processChunk() [15.65ms]
(pass) ZstdCompress: reset() in an open frame > on the native handle, reports to onerror and keeps what is open [13.84ms]
(pass) ZstdCompress: reset() in an open frame > on the native handle, after output and then a write that gives none [6.19ms]
(pass) ZstdCompress: reset() in an open frame > on the native handle, after a write() on the thread pool [10.83ms]
(pass) ZstdC
... (truncated)

release with fix: all passed
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped) in 746ms (unchanged)
ninja: Entering directory `/workspace/bun/build/release'
[1/344] gen generated_host_exports.rs
generated_host_exports.rs: 111 exports (lazy=4, generic=107, rust=0); 263 extern-C blocks audited
[2/343] gen the table of built-ins
builtins table: operands without uses: none
builtins table: 2011 host entries have a result that is not described; a program in which a value may be anything holds what any host class needs: 0 modules, 15 functions
[3/256] cxx obj/src/jsc/bindings/webcore/streams/JSPullIntoDescriptor.cpp.o
[4/256] cxx obj/src/jsc/bindings/webcore/streams/JSCrossRealmTransformState.cpp.o
[5/256] cxx obj/src/jsc/bindings/webcore/streams/JSCompressionStream.cpp.o
[6/256] cxx obj/src/jsc/bindings/webcore/streams/JSDecompressionStream.cpp.o
[7/256] cxx obj/src/jsc/bindings/webcore/streams/JSCountQueuingStrategy.cpp.o
[8/256] cxx obj/src/jsc/bindings/webcore/streams/JSByteLengthQueuingStrategy.cpp.o
[9/256] cxx obj/src/jsc/bindings/webcore/streams/JSDirectStreamController.cpp.o
[10/256] cxx obj/src/jsc/bindings/webcore/streams/JSCompressionStreamShared.cpp.o
[1
... (truncated)

diff hotspot

src/runtime/node/zlib/NativeZstd.rs                |  19 +-
 .../test-zlib-zstd-reset-incomplete-frame.js       | 129 ++++++++++
 .../zlib/zlib-zstd-reset-incomplete-frame.test.ts  | 279 +++++++++++++++++++++
 3 files changed, 426 insertions(+), 1 deletion(-)

gate history · 1 passed · 0 rejected · iteration 1

evidence per changed file

file                                                      reads  edits  tests
src/runtime/node/zlib/NativeZstd.rs                           2      3      8
…/test/parallel/test-zlib-zstd-reset-incomplete-frame.js      0      0     11
…t/js/node/zlib/zlib-zstd-reset-incomplete-frame.test.ts      0      1      5

…output reset() on a ZstdCompress stream dropped the context of a frame whose first bytes were already in the output. The next frame followed that fragment, and the output failed to decode with ZSTD_error_corruption_detected. Node.js v26.11.0 and later refuse that reset (nodejs/node#66088). The native handle reports ERR_ZLIB_INCOMPLETE_FRAME through onerror, and the stream is destroyed. The zstd Context now records that the open frame has given output, and Context::reset returns the same error before it makes a new context.

robobun · 2026-10-29T14:16:53Z

^{Updated 3:33 PM PT - Oct 29th, 2026}

❌ @robobun, your commit 4209187 has 2 failures in Build #135361 (All Failures):

test/aot/build-scaling/build-scaling-2.test.ts - code 1 on 🍎 any aarch64
Failed to create agent for 🐧 3.23 aarch64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 3.23 aarch64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 3.23 aarch64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 3.23 aarch64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 3.23 aarch64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - cargo-test

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 25.04 x64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 aarch64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 aarch64 - test-bun

CapacityLimitExceeded

Failed to create agent for 🐧 13 aarch64 - test-bun

CapacityLimitExceeded

🧪 To try this PR locally:

bunx bun-pr 47376

That installs a local version of the PR into your bun-47376 executable, so you can run:

bun-47376 --bun

robobun · 2026-10-29T14:17:05Z

Status

How the problem reproduces, on main (da867c6) and on Bun 1.4.3:

import zlib from "node:zlib";
const z = zlib.createZstdCompress(), out = [];
z.on("error", e => console.log("error", e.code));
z.on("data", d => out.push(d));
await new Promise(r => z.write("hello", r));
await new Promise(r => z.flush(r));
z.reset();
if (!z.destroyed) {
  z.end("world");
  await new Promise(r => z.on("end", r));
  console.log(zlib.zstdDecompressSync(Buffer.concat(out)).toString());
}

main: reset() reports nothing, and zstdDecompressSync then throws ZSTD_error_corruption_detected.
Node.js v26.12.1 and this PR: error ERR_ZLIB_INCOMPLETE_FRAME.

The fix is this pull request, #47376. It is a draft on top of #47079. The gzip half is #47364.

CI: no failure comes from this change. The two builds of this tree (135244, 135361) are red for two reasons:

CI could not start the machines for part of the Linux test jobs (CapacityLimitExceeded when it creates the agents). Those jobs were cancelled.
In build 135361, one macOS aarch64 shard fails test/aot/build-scaling/build-scaling-2.test.ts: twice as many functions cost 2.57 times the peak memory, and 2.5 is allowed. This PR does not touch bun build --compile --aot. The test fails on main too, and test: one shape of build-scaling grows 2.58 times in memory #47329 changes its budget. Replace the zstd C library with a port to safe Rust #47079 has the same change since 79995be, which is after this build.

In build 135244 every build job passes, and the full test suite passes on Alpine x64, Alpine aarch64, Debian x64 with ASAN, Windows x64 and Windows aarch64. The second commit is empty and only started the second build.

github-actions Bot added the claude label Oct 29, 2026

robobun mentioned this pull request Oct 29, 2026

node:zlib: refuse reset() of a gzip member that is open and has given output #47364

Open

ci: retrigger

4209187

Navigation Menu

Repository navigation

node:zlib: refuse reset() of a zstd frame that is open and has given output - #47376

node:zlib: refuse reset() of a zstd frame that is open and has given output#47376
robobun wants to merge 2 commits into
claude/zstd-rust-replacement-4qwmbqfrom
robobun/042207aa/zstd-reset-incomplete-frame

robobun commented Oct 29, 2026 •

edited

Loading

Uh oh!

robobun commented Oct 29, 2026 •

edited

Loading

Uh oh!

robobun commented Oct 29, 2026 •

edited

Loading

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

robobun commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Background

Downsides

What each runtime does

The error

One flag where Node.js has two

Tests

After an accepted reset()

Rows that still differ from Node.js

Uh oh!

robobun commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

robobun commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Status

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

robobun commented Oct 29, 2026 •

edited

Loading

After an accepted `reset()`

robobun commented Oct 29, 2026 •

edited

Loading

robobun commented Oct 29, 2026 •

edited

Loading