refactor: replace remaining Bun APIs (zstd, mmap, CryptoHasher, file writer)

[BYK]

Summary

Fourth step of the Bun → Node.js migration (follows #967, #970, #984). Replaces the remaining Bun-specific APIs in src/ — the "Group D" items that required more careful handling.

Changes

src/lib/bspatch.ts (rewritten):

• Bun.zstdDecompressSync() → zstdDecompressSync() from node:zlib
• DecompressionStream('zstd') → createZstdDecompress() from node:zlib piped through a Node Readable→Web ReadableStream bridge
• Bun.mmap() → removed entirely; uses readFile() for both paths (copy-then-read and direct-read fallback)
• Bun.CryptoHasher("sha256") → createHash("sha256") from node:crypto
• Bun.file(destPath).writer() → createWriteStream(destPath) from node:fs

src/lib/upgrade.ts:

• Bun.file(destPath).writer() → createWriteStream(destPath) from node:fs

src/lib/api/sourcemaps.ts:

• Bun.zstdCompress(buf, { level: 3 }) → zstdCompress() from node:zlib

src/lib/telemetry/zstd-transport.ts:

• Removed globalThis.Bun.zstdCompress dynamic access and BunZstdHost type
• Replaced with direct zstdCompress from node:zlib (always available in Node 22.15+)
• Removed belt-and-braces fallback (zstd can't disappear at runtime with node:zlib)
• hasZstdSupport() now checks typeof zstdCompressCb === "function" directly

Tests updated (test/lib/telemetry/zstd-transport.test.ts):

• Removed 4 tests for globalThis.Bun.zstdCompress fallback paths (no longer applicable)
• Replaced Bun.zstdDecompress with zstdDecompressSync in assertions

Result

Zero non-comment Bun.* API calls remain in src/. The only bun: reference left is the require("bun:sqlite") fallback in sqlite.ts, which will be removed when the test runner migrates to Vitest.

All 7014 tests pass, 0 failures.

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://cli.sentry.dev/_preview/pr-986/
Built to branch gh-pages at 2026-05-20 16:04 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[github-actions]

Codecov Results 📊

✅ 7014 passed | Total: 7014 | Pass Rate: 100% | Execution Time: 0ms

📊 Comparison with Base Branch

Metric	Change
Total Tests	📉 -4
Passed Tests	📉 -4
Failed Tests	—
Skipped Tests	—

All tests are passing successfully.

✅ Patch coverage is 80.65%. Project has 14204 uncovered lines.
✅ Project coverage is 77.14%. Comparing base (base) to head (head).

Files with missing lines (2)

File	Patch %	Lines
src/lib/bspatch.ts	75.51%	⚠️ 12 Missing
src/lib/upgrade.ts	71.43%	⚠️ 6 Missing

Coverage diff

@@            Coverage Diff             @@
##          main       #PR       +/-##
==========================================
+ Coverage    77.10%    77.14%    +0.04%
==========================================
  Files          322       322         —
  Lines        62112     62128       +16
  Branches         0         0         —
==========================================
+ Hits         47884     47924       +40
- Misses       14228     14204       -24
- Partials         0         0         —

---

Generated by Codecov Action

[cursor]

Zstd encoding selected without runtime support check

High Severity

pickUploadEncoding returns "zstd" whenever the server advertises it, without checking zstdCompressAsync. On Node < 22.15, encodeChunk silently returns raw bytes (falls through both if branches), but uploadChunk still sets Content-Encoding: zstd. The server then tries to zstd-decompress uncompressed data and fails. Additionally, zipCompression is set to "stored" (no deflate) because a wire codec was selected—compounding the issue.

Additional Locations (2)

• src/lib/api/sourcemaps.ts#L208-L229
• src/lib/api/sourcemaps.ts#L277-L281

 

^{Reviewed by Cursor Bugbot for commit f652595. Configure here.}

[cursor]

Zstd bridge decompresses eagerly instead of on-demand

Medium Severity

createZstdStreamReader pipes the full compressed block through a flowing Node stream immediately upon construction, decompressing eagerly. Both diff and extra readers are created (lines 304–307) before loadOldBinary awaits, so both blocks can fully decompress and buffer in memory concurrently—contradicting the module's "minimal memory usage" design. The old DecompressionStream approach was pull-based and only decompressed on demand.

 

^{Reviewed by Cursor Bugbot for commit f652595. Configure here.}

[sentry-warden]

Node.js WriteStream backpressure ignored, causing unbounded memory growth on large downloads

The writer.write(chunk) return value is never checked; when the internal buffer is full (write() returns false), the loop should await the drain event before writing more chunks, otherwise all decompressed data accumulates in the stream's internal buffer and can exhaust memory for large binaries.

Evidence

• writer is a fs.WriteStream (Node.js Writable); write() returns false when the highWaterMark is exceeded, signalling the caller to pause.
• The for await loop over the Web ReadableStream has no backpressure coupling to the WriteStream; every chunk is handed to write() immediately regardless of buffer state.
• The Bun FileSink.write() it replaces was synchronous/memory-mapped and did not have this buffering concern.
• Decompressed upgrade binaries can be tens to hundreds of MB; if disk I/O stalls (e.g. slow/network-mounted FS), the full decompressed binary can be held in the write buffer.

Suggested fix: Await the drain event when write() returns false

Suggested change

	writer.write(chunk);
	const ok = writer.write(chunk);
	if (!ok) {
	await new Promise<void>((res) => writer.once("drain", res));
	}

_{Identified by Warden find-bugs · 86Y-GT9}

[sentry]

Bug: On Node.js < 22.15, uploadChunk sends uncompressed data with a Content-Encoding: zstd header because encodeChunk silently fails to compress but the header is set regardless.
_{Severity: HIGH}

Suggested Fix

encodeChunk should return an object indicating both the resulting buffer and the encoding that was actually applied (e.g., { data: Buffer, encoding: 'zstd' | 'identity' }). The uploadChunk function should then use this returned encoding to correctly set the Content-Encoding header only when the data is actually compressed. This prevents a mismatch between the payload and its encoding header.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/lib/api/sourcemaps.ts#L222-L229

Potential issue: On Node.js versions older than 22.15, the `zstdCompressAsync` function
is unavailable. When a server advertises `zstd` support, the `encodeChunk` function is
called with `encoding: "zstd"` but falls through and returns an uncompressed buffer
because `zstdCompressAsync` is falsy. However, the `uploadChunk` function proceeds to
set the `Content-Encoding: zstd` header based on the initial `encoding` parameter,
without verifying if compression actually occurred. This results in sending uncompressed
data with a `zstd` header, causing the server to fail during decompression and reject
the sourcemap upload.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 3 total unresolved issues (including 2 from previous reviews).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 054955a. Configure here.}

[cursor]

Duplicated feature-detection comments in two files

Low Severity

The two-line comment "zstdCompress is available in Node 22.15+. Feature-detect to avoid crashing…" is repeated verbatim twice in a row — a copy-paste error. The same duplication exists in zstd-transport.ts lines 82–85.

Additional Locations (1)

• src/lib/telemetry/zstd-transport.ts#L81-L85

 

^{Reviewed by Cursor Bugbot for commit 054955a. Configure here.}