fix(blob): decompress (inflate) compressed blobs on read instead of re-deflating

[kriszyp]

Summary

FileBackedBlob.bytes() read DEFLATE-compressed blobs incorrectly: for DEFLATE_TYPE it called deflate() on the already-compressed on-disk body (double-compressing) instead of decompressing, and inflate wasn't even imported. The streaming read path (stream()) had a // TODO: Implement support for decompression and likewise returned the raw compressed bytes. Net effect: reading any DEFLATE-compressed blob returned corrupt data.

Why it was latent

Blob compression is exposed (compress?: boolean on BlobCreationOptions) but off by default and unused — nothing in harper/harper-pro sets compress: true for blobs. So this never fired in practice. This is a correctness fix that must be in place before anyone enables compress: true.

The fix

Buffered path (bytes()):

• Inflate the body for DEFLATE_TYPE (was deflate). start/end ranges index into the uncompressed content, so we inflate first, then slice.
• Completeness of a compressed blob can't be judged from the header size (which is the uncompressed length) vs the compressed on-disk body length, and the header size is written up front when the size is known — so neither bytes nor header size is a reliable in-flight signal. Completeness is instead verified via the writer's existing fileId + ":blob" lock (new mustVerifyViaLock probe in waitForCompletion): if the writer still holds the lock we wait for release and re-read; otherwise we re-read once and inflate. The ERROR_TYPE, UNKNOWN_SIZE, and lock-wait semantics are preserved. The uncompressed path keeps its exact size-vs-body completeness check (refactored for clarity, behavior unchanged).

Streaming path (stream()):

• On detecting DEFLATE_TYPE in the header (first read), delegate to the buffered inflate path and emit the decompressed result as a single chunk. This is the correct-or-safe choice the task sanctioned: it never streams compressed garbage. A true streaming inflate would require reworking the position-seeking / watcher framing (you can't seek into a deflate stream by uncompressed offset), which I judged too risky for a correctness fix.

Tests

Added to unitTests/resources/blob.test.js:

• Compressed round-trip via bytes() and stream() — asserts decompressed output equals the original.
• Ranged read (slice(300, 400)) over a compressed blob, via both bytes() and stream().

Both fail before the fix (the double-compress produces a body shorter than the uncompressed size → "Incomplete blob" / inflate error) and pass after. blob.test.js (31) and the full test:unit:resources suite (843) are green; lint and TypeStrip (node --experimental-strip-types --check) clean.

Where to look

• The mustVerifyViaLock lock-probe logic in waitForCompletion — this is the load-bearing correctness piece. The cross-model reviews (Codex, Gemini) found no deadlock / incorrect-throw issues here, but it's the part most worth a careful read.
• The stream() buffered-fallback decision: deliberate tradeoff (correctness over true streaming inflate). Open for discussion if a streaming inflate is wanted later — flagged as a known limitation, not a regression.

Note: this PR touches resources/blob.ts but only FileBackedBlob.bytes() and stream() — disjoint from PR #1387 (isBlobFileComplete/findIncompleteBlobRefs), so they should coexist cleanly.

🤖 Generated by Claude Code (model: claude-opus-4-8). Cross-reviewed by Codex and Gemini; no open blockers.

[gemini-code-assist]

Code Review

This pull request implements decompression support for file-backed blobs, replacing the incorrect use of deflate with inflate when reading compressed blobs. It introduces robust handling for concurrent writes of compressed blobs using lock verification and updates the streaming read path to handle compressed content by delegating to the buffered inflate path. Unit tests have been added to verify round-tripping and ranged slicing of compressed blobs. The reviewer suggested wrapping controller.enqueue and controller.close in try-catch blocks to prevent runtime crashes if the stream is cancelled or closed while blob.bytes() is resolving.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[claude]

Reviewed; no blockers found.

[Ethan-Arrowood]

Code looks good — clear correctness fix (the double-deflate → inflate bug, plus the stream() TODO), and I traced the waitForCompletion lock-probe logic that does the heavy lifting for compressed-completeness; it holds up and terminates cleanly. Two non-blocking notes for the record: compressed reads are now lock-dependent for completeness (a writer dying while holding the :blob lock would stall the read), and stream() buffers the whole compressed body in memory rather than a true streaming inflate — both fine given compress is unused/off by default today.

One thing before merge: the branch is currently conflicting with main (needs a rebase, almost certainly against the recent blob.ts changes). Approving on the assumption the rebase is mechanical — if it touches anything substantive in bytes()/stream(), give me a ping for a quick re-look; otherwise good to merge at your discretion once it's rebased and CI is green.

_{sent with Claude Opus 4.8}