[voltcrash]

Opening a valid TAR with a 40 MiB large.txt copies and retains another 41,943,040-byte payload even though entry previews reject it at 10 MiB. Keep oversized regular files in the listing, but store a null marker instead of copying their contents; opening them still returns Entry previews are limited to 10 MB. Small and empty entries keep working.

This qualifies as a small, focused fix for an obvious allocation bug under CONTRIBUTING.md's exception: it preserves the existing preview behavior and limits. TAR hard links and ZIP ranged reading (#33941) are outside this change. A fresh open-PR search found no matching fix.

Proof: the focused worker test fails on the original code for the 10 MiB + 1 and 40 MiB cases, then all three boundary/size cases pass with this fix. Each archive includes small files before and after the large entry and an empty file; assertions cover listing metadata, copied bytes, entry contents, the size-limit error, and missing paths. Run vp test run apps/web/src/components/files/binaryPreview.worker.test.ts.

A Node --expose-gc harness executing the worker parser measured the 40 MiB entry's copied bytes and payload buffers retained by the worker map: both were 41,943,040 before and 0 after. The listing and error were identical. This measures allocation/retention, not a speedup; none is claimed.

Integrated verification used the isolated dev app and the real BinaryViewer and worker: the mixed TAR listed all four entries, large.txt showed the existing limit error, and returning to the archive then opening after.txt rendered after.

vp run check:changed upstream/main passed (format, lint, both knip passes, affected-package typechecks, all 3 worker cases, React compiler coverage). The existing bounded-binary browser suite could not start tests: Chromium failed to connect to its Vitest browser session on both attempts. The real-viewer verification above ran separately through the Browser panel.

Reviewed with review-loop: 1 round with Claude Opus 5.5. Reviewer verdict: approved. No required findings; retained the audited 40 MiB regression fixture despite a suggestion to use boundary cases only.

Created with GPT-6.1 Sol in the Codex harness through T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 0950a50

Macroscope's review found this PR approvable — Oversized TAR entries remain listed but no longer incur payload copies for previews that are already blocked by the existing size limit. The change is confined to transient browser-worker memory and preserves existing preview behavior.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The TAR preview worker records only the size of entries larger than ARCHIVE_ENTRY_MAX_BYTES. Requests for those entries return the existing preview-limit error. A new test checks metadata, payloads, hard links, and missing-entry behavior.

Changes: TAR entry limits

Layer / File(s)	Summary
Oversized TAR entry storage and retrieval apps/web/src/components/files/binaryPreview.worker.ts, apps/web/src/components/files/binaryPreview.worker.test.ts	The worker stores a numeric size instead of copying bytes for oversized entries. It reports the stored size in metadata and returns the preview-limit error when a size-only entry is requested. The test checks eligible payloads, empty entries, hard links, oversized entries, and missing paths.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: maria-rcks

Merge Risk: Minimal · up to 6eb80

This change avoids copying oversized TAR entries during preview while keeping the listing and the existing size-limit error. No concrete merge-blocking risk was found.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "perf(web): skip oversized TAR preview payload copies" matches the main change. The worker now stores only a size marker for TAR entries above the 10 MB limit instead of copying their payloa…
Description check		The description follows the template's main sections: Problem, Change, Scope, and Verification. It explains the allocation bug, the null-marker fix, and the 10 MiB limit behavior. It justifies the no-…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title "perf(web): skip oversized TAR preview payload copies" matches the main change. The worker now stores only a size marker for TAR entries above the 10 MB limit instead of copying their payloads. The title is a conventional commit with a specific scope and describes the primary change. It does not cover the test additions, but that is expected.

Full details: Description check

Explanation

The description follows the template's main sections: Problem, Change, Scope, and Verification. It explains the allocation bug, the null-marker fix, and the 10 MiB limit behavior. It justifies the no-issue exception under CONTRIBUTING.md and gives focused test commands plus measured before and after results. It also states what was not verified: the browser suite failed to start. The Problem section is implicit rather than labeled as a separate statement, and the Scope section does not link an issue, but the author explains why none is needed. The description also includes a review-loop and model attribution, which the template asks for when an agent was used. Overall it is mostly complete.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 2bee33e
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: b12f5f60-f39f-4310-a7ef-ce3bae77dc28

Commits

Reviewing files that changed from the base of the PR and between 8c492c4 and 6eb8030.

Files selected for processing: 2

• apps/web/src/components/files/binaryPreview.worker.test.ts
• apps/web/src/components/files/binaryPreview.worker.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 4 remain after this review.

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Verified in a real dev environment

The same flow ran on main (d2c25950b4) and on this PR's head (0950a50ec0), using vp run dev with isolated state:

1. Created a git repo with mixed.tar: before.txt (6 B), large.txt (41,943,040 B), empty.txt (0 B), and after.txt (5 B). The repo also had small.zip.
2. Added it as a project through the web app. Ran a real Claude Haiku 5.5 turn that listed the archive and linked mixed.tar.
3. With Playwright and Chrome, clicked the link to open the file preview. Then opened large.txt, went back to the archive, and opened after.txt. Last, opened small.zip from the file tree and opened before.txt.
4. After the archive listing loaded, attached to the binaryPreview.worker target over CDP. Forced a GC and read Runtime.getHeapUsage.

main  after opening mixed.tar  jsHeapUsed 0.8 MB  backingStorageSize (ArrayBuffers) 40.5 MB
PR    after opening mixed.tar  jsHeapUsed 0.8 MB  backingStorageSize (ArrayBuffers)  0.5 MB

The 40 MB copy of the blocked large.txt payload is gone. Nothing visible changed:

• All 4 entries are listed with the same sizes.
• large.txt still shows "Entry previews are limited to 10 MB."
• after.txt renders after.
• The ZIP preview still lists its entries and renders before.txt.

Listing, main:

Listing, PR:

large.txt, main:

large.txt, PR:

after.txt after returning to the archive, PR:

ZIP preview, PR:

Full PR flow (12.8 s): https://uploads-production-47e4.up.railway.app/files/dd84b826-6fd7-4f43-8f58-5f699504e5fb/pr-tar-preview.mp4

Not verified

• The desktop (Electron) and mobile clients. The change is in the web preview worker that desktop wraps. The mobile app does not use this worker.
• Remote or tunnel connections. Only a local dev server was used.

[juliusmarminge]

Evidence

Real web app on the same Linux machine, Chrome 151.0.7922.108, 1440×900, dark theme, fresh isolated databases and synthetic replay history. Five fresh browsers per commit per archive.

Steps: open right panel → Files → mixed.tar; measure worker open-request-to-archive-reply latency; force worker GC three times and record backing storage; click large.txt; verify the existing 10 MB limit error; return to the listing and open after.txt. Repeat with the 1-byte control archive for the memory baseline.

The mixed.tar median fell from 15.4 ms to 2.7 ms. The 12.7 ms improvement exceeds both run spreads (base 5.1 ms; head 2.6 ms). Base retained exactly 41,943,040 extra bytes relative to its control; head retained zero extra bytes relative to its control. Every memory series had zero spread. All ten mixed.tar runs preserved the listing, error, and subsequent text preview.

Before	After
9db3cb10916c	8c492c457a18
15.4 ms median; 11.5–16.6 ms range	2.7 ms median; 1.3–3.9 ms range
42,436,421 backing-storage bytes	493,500 backing-storage bytes
Before recording	After recording
Before raw measurements, control	After raw measurements, control

Measurement driver · Fixture generator · Summary generator · Summary data · Reproduction instructions

Timing covers the real app's worker request and response, excluding archive fetching and React rendering. Control timings are not used for the speed comparison. Captures were visually inspected before upload.

Not shown:

• End-to-end click-to-render latency was not measured; the timing comparison covers worker open-request to archive reply.
• Transient allocation totals were not separately profiled; retained worker backing storage was measured after forced garbage collection.

[juliusmarminge]

Evidence

Steps: open Files → mixed.tar, inspect all four entries, open large.txt, return to the listing, and open after.txt. Repeat with a 1-byte control. Same Linux machine, Chromium 156.0.8078.4, 1280×800, dark theme, isolated fresh databases, five fresh browsers per archive per commit.

Before	After
2bee33eb19	6eb80309a1
Worker parse median 15.6 ms, range 14.7–25.6 ms	Worker parse median 0.9 ms, range 0.8–1.0 ms
Retained backing storage 42,438,440 bytes; 41,943,040 bytes above control	Retained backing storage 495,896 bytes; 0 bytes above control
Before recording	After recording

The worker-processing median improves by 14.7 ms, exceeding the combined run spreads of 11.1 ms. Memory spread is 0 bytes in all four batches. A separate oversized-slice probe records 41,943,040 copied bytes before and 0 after. All behavior checks pass on both commits. End-to-end click-to-listing ranges overlap, so this does not establish a user-visible speedup.

Raw measurements · Text output · Measurement driver · Copy probe · Fixture generator · Report generator · Reproduction instructions.

Recordings retain normal playback speed and are cropped and trimmed to the Files interaction. Readable stills hide the file explorer after measurement.

Not shown:

• End-to-end user-visible speedup: click-to-listing medians were 909.6 ms on base and 865.0 ms on head, but ranges overlapped and the improvement was smaller than the run spread. The demonstrated timing improvement is confined to worker archive processing.