Current checkpoint — 90ced0ed6
The full unchanged fetch-gzip.test.ts now passes 24 tests / 0 failures / 43 assertions, up from the published parent's 22 pass / 2 fail / 42 assertions, matching the pinned Bun release control. The original 1,025 MiB decompressed response remains unchanged. HTTP decoding no longer imposes Home's arbitrary 1 GiB cap; responses that received zero compressed body bytes are empty, while a started truncated gzip stream still fails at an empty final chunk. This ports the pinned Rust contract.
All four further complete fetch files pass: streaming 110 passes / 5 TODOs, chunked trailing 23/23, connection headers 10/10, body-stream excess 4/4. Streaming assertion totals depend on transport chunk boundaries (final 436, pinned control 446); no assertions were removed. The entire zlib file retains 378 passes / 2 skips / 0 failures / 434 assertions, with bounds 9/9 and reentrancy 3/3. #528 separately retains the installer's required 2 GiB safety limit; #526 repairs EOF completion.
Native build 17/17; runtime units 1,824 pass / 19 skips / 0 failures (19/19 steps); runtime regressions 56/56, including 25 native files. All 46 measured upstream test sources match the exact Bun pin. No assertion, workload, deadline, skip or TODO was weakened. Full logs and failed controls remain in the evidence records.
Evidence: zig-out/eof-fetch-{parent,candidate1,release-control,final4}.json, eof-zlib-final4.json, eof-unit4.log, eof-source-integrity4.json, eof-build4-binary.json, and eof-implementation-pin.json. Empty-body, truncated-stream and output-limit unit cases all executed successfully.
Published on codex/runtime-port as Chris Breuer without coauthors, not merged to main. Verification uses the shared Darwin checkout; unrelated compiler changes are excluded. Linux/Windows behavior and branch integration remain unverified; this issue stays open for those checks. Skips/TODOs and full source ownership are not completed parity. The full port and 100% logical Bun-suite compatibility under #66 remain incomplete.
Original reproduction (before this checkpoint)
Follow-up to #66 and #526, found while verifying EOF-delimited HTTP response completion. The complete unchanged js/web/fetch/fetch-gzip.test.ts at source pin 4982b91e3702094330f3be3883354c52b8c01323 has two pre-existing native failures:
fetch() with a buffered gzip response whose decompressed size exceeds 1 GiB works: the child reports ZlibError instead of returning the complete original-size body.empty compressed responses > empty gzip body via chunked resolves as empty: an empty chunked gzip response reports ZlibError instead of resolving as empty.
Published Home 9b3a5c1ad2d7e7d32d93ccb9464b2f3f82db03f3 and the initial #526 candidate both produce 22 pass / 2 fail / 42 assertions. Pinned Bun release 1.4.0-canary.1+4982b91e3 produces 24 pass / 0 fail / 43 assertions. The candidate's EOF notification fix does not resolve these decompression boundaries. Do not reduce the >1 GiB workload or change empty-body expectations; port the real decompressor behavior, preserve malformed-stream handling, and rerun the complete unchanged suite.
Adjacent unchanged fetch suites pass: streaming 110 tests (5 TODOs), chunked trailers 23, connection headers 10, and excess-body framing 4. Their passes do not establish gzip parity. All five source files are byte-identical to the pin.
Evidence: zig-out/eof-fetch-{parent,candidate1,release-control}.json, full per-file stdout/stderr, and eof-fetch-source-integrity.json. Darwin only; other platforms and full native parity remain unverified. #66 remains incomplete.