[only21mil]

Problem

When the PDF.js fallback loads a PDF, readBoundedDocument rejects a response with an error status or a declared Content-Length over the 50 MiB limit. It throws without cancelling the response body. Nothing reads or cancels that body afterwards, and the viewer clears its timeout and shows the error. So the browser keeps downloading the file it already refused, until the viewer unmounts, retries or switches source.

In Chromium, after the "unavailable or too large" error appeared, a 50 MiB + 1 byte response still downloaded in full. The existing check for a body that grows past the limit while streaming already cancels its reader. Only the early rejection missed it.

Change

Cancel the response body before throwing on those two early checks. The cancel isn't awaited and its rejection is ignored, so a slow or failing cancel can't delay or replace the error the viewer shows. The limit, the messages and the streamed-read path are unchanged.

Scope and approval

A small fix for an obvious resource bug, under the obvious-bug exception. It adds one cancel call to the PDF fallback's fetch helper, plus a test. The native browser PDF viewer doesn't use this helper and is unaffected.

The font preview (readFont in FontViewer.tsx) and the large-text worker's error-status check have the same early-rejection pattern. I left them out to keep this PR to one change. I can fold them in or send them separately.

Verification

• readBoundedDocument.test.ts covers an error status and a declared oversize body. Each row checks the body's cancel runs and the existing error still comes through when cancel throws. Both rows fail on main. Without the .catch, the run reports unhandled rejections.
• Chromium 148 (Vitest browser mode) ran the real helper against a local server streaming 52,428,801 bytes with the 50 MiB limit. 1.5 s after the error:
  • before: the server had sent all 52,428,801 bytes, for both the 200 and the 503 response.
  • after: the connection was closed, after 4 to 6 MiB.
• The same check in Node 22's fetch showed the connection closed after the fix and held open before it.
• Files panel in the web client, Chrome 158 on Linux, with a local proxy answering one PDF with a 503 and a 64 MiB body. On main the request stayed open after the error until the viewer closed: about 7 MB taken with no-store, about 58 MB within a second with private, max-age=3600. On this branch it was cancelled (net::ERR_ABORTED, canceled: true) 1 to 2 ms after the 503 headers, on first open and on Try again, with the same error text.
• PdfViewer.browser.test.tsx passes. vp run check:changed passes.

Not checked:

• The desktop app and Safari or iOS. They use the same helper; only Chromium and Node fetch were run.
• No screenshots: the error view looks the same before and after. Only the network behaviour changes.
• No savings measured on a real remote connection.

Prior PRs

#21469 added this helper with the other document previews. #25496 also edits PdfViewer.tsx and doesn't touch this helper. I found no open PR that changes this file.

Generated with Claude Opus 5.5 in T3 Code Nightly

[macroscopeapp]

Approvability

Verdict: Approved at fa5fda6

Macroscope's review found this PR approvable — Rejected PDF downloads now release their response bodies without changing preview limits or error behavior. The change is limited to resource cleanup and presents no obvious material risk.

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

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

When a response is not OK or its declared content length exceeds the limit, readBoundedDocument attempts to cancel its body before throwing the existing error. Tests cover both conditions and verify that cancellation failures do not replace the error.

Changes: Bounded document rejection

Layer / File(s)	Summary
Rejection and cancellation behavior apps/web/src/components/files/readBoundedDocument.ts, apps/web/src/components/files/readBoundedDocument.test.ts	The helper attempts to cancel the response body for non-OK responses and responses above the size limit. Tests cover HTTP 503 and an 11-byte declared length against a 10-byte limit, including cancellation callbacks that throw.

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

Change: Bug fix

Possibly related PRs

• pingdotgg/t3code#21469: Introduced readBoundedDocument for the built-in PDF viewer.

Suggested labels: bugfix

Suggested reviewers: maria-rcks

Merge Risk: Minimal · up to fa5fd

No actionable merge-blocking risk was identified in the response-body cancellation change.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: releasing rejected PDF response bodies in the web application.
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.
Description check		The description includes all required sections. It explains the problem and change, justifies the scope under the obvious-bug exception, and reports focused tests, results, and limitations.

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: 5fe18d7
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: dda1534a-07ae-4139-9c75-c617230ffe22

Commits

Reviewing files that changed from the base of the PR and between 5fe18d7 and fa5fda6.

Files selected for processing: 2

• apps/web/src/components/files/readBoundedDocument.test.ts
• apps/web/src/components/files/readBoundedDocument.ts

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

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified as-is at fa5fda60ef92a22d8a6a499401dc22e26accdd18 on a linux boat vm. reproduced first on github/main at 8b74a69019, then ran the exact pr head with one dev server at a time. no source changes or pushes.

used the real web client, repo playwright and /usr/bin/google-chrome (151), with native pdf support disabled in chrome preferences. created projects and threads through the app. real codex gpt-6.1-sol turns created a two-page 870-byte pdf and a 67,108,864-byte pdf in a real git repository. the pr server also completed a read-only codex turn confirming both sizes.

opened the documents through the files panel, which reaches PdfViewer and readBoundedDocument. observed the real signed asset requests with chrome devtools protocol, with cache disabled and the same browser network configuration on both revisions. no intercepted responses, mock endpoints or direct helper calls.

main: HTTP 200, Content-Length 67108864
  207 ms: response headers
  287 ms: unavailable/too-large error visible
10806 ms: request still pending; 58,720,256 response bytes observed

pr: HTTP 200, Content-Length 67108864
  472 ms: response headers
  473 ms: loadingFailed, net::ERR_ABORTED, canceled=true
  554 ms: same error visible

pr retry: HTTP 200, Content-Length 67108864
  235 ms: response headers
  252 ms: loadingFailed, net::ERR_ABORTED, canceled=true
  256 ms: same error visible

these are local browser observations, not a remote bandwidth benchmark. the visible error remains unchanged. cancellation also works on retry. the small pdf still renders both pages; next page, zoom, find with one highlighted match, and switching back from a rejected document all work.

blacksmith passed the existing helper tests (2 cases), the existing pdf viewer browser test, and vp run check:changed 15fe2832727893cbdd2214383f9f971474849695 (explicit pr base because the worker snapshot initially lacked merge-base history). format, lint, knip, affected typechecks, selected tests and react compiler check passed.

before, main:

after, pr:

Not verified

• long non-2xx response cancellation through the real app: local asset errors have short bodies, so the sustained-download case was unavailable without mocks. the existing helper test covers status 503 and cancellation failure.
• electron, native ios/android, safari, macos/windows, relay/tunnel connections and real remote bandwidth savings were not exercised on this linux chromium setup.

[only21mil]

Note

🤖 Opus 5.5 replying on behalf of Victor.

@maria-rcks thanks for the test; it showed the head cancelling the too-large 200 download in the real files panel. For the open item we put a local proxy in front of the dev server that answered one PDF with a 503 and a 64 MiB body, then opened that PDF from the files panel in Chrome 158 on Linux on main 20c3dd3689 and on the head fa5fda60ef, recording the request with the DevTools protocol. On main the request stayed open after "This file is unavailable or too large to preview." appeared, until the viewer closed: with no-store Chrome took about 7 MB and then held the connection, and with the asset route's private, max-age=3600 it took about 58 MB within a second. On the head the same error showed and the request ended with loadingFailed, net::ERR_ABORTED, canceled: true 1 to 2 ms after the 503 headers, on first open and on Try again; Electron, Safari, mobile and real remote bandwidth stay unverified.