[waleedlatif1]

Summary

• Public share links read the whole shared file into memory under the 100 MB transfer ceiling, so any share over 100 MB answered 413. The share viewer couldn't render it and its Download button (same URL) failed too. In production that is ~8% of share content requests, all from files over the ceiling.
• readPublicFileShareContent now decides once, right after the grant is read and the file is admitted. A file served as its stored bytes (servesStoredBytes, the predicate the serve route uses) comes back as a stream result; a page, generated document or preview=1 image is built whole exactly as before (buffer result).
• The stream result's open(range) reads the whole object or one inclusive span from storage, then rechecks the grant, the file revision and its secret provenance before handing the stream out, the same guarantees finish() gives a buffered read. It reports the delivery and audits once per view (a download, or the first span of a player's ranged reads), not once per seek.
• The route presents a stream result with createStoredFileStreamResponse (200 / 206 / 304 / 416, Accept-Ranges, strong ETag), keeping the token URL's revalidate cache policy and nosniff. The HEAD check no longer applies the buffered ceiling or the document sniff to files that stream.
• The public file content source declares servesByteRanges, so video and audio on share pages stream and seek instead of downloading the whole file into the tab.
• The two copies of the public-share download audit now share one builder.

Type of Change

• Bug fix

Testing

• content-sharing.integration.ts (real PostgreSQL + local storage), 13/13: a new check streams a stored object past the 100 MB ceiling (exact full and tail-range bytes), refuses a previously opened read once the share is disabled, and keeps pages and generation sources off the stream. The existing mid-read revocation/password/archive/provenance check now injects the change during either read path. Removing the post-open recheck turns both red.
• Local E2E against next dev with a real public share of a 151 MB MP4, 11/11: byte-exact full GET, exact 206 slices incl. suffix, 416, 304, HEAD 200, a small text share unchanged, one audit row per view, the /f/<token> viewer playing and seeking and its Download button saving the exact file, and a disabled share refusing a fresh ranged request.
• lib/public-shares and app/api/files unit suites; check:api-validation:strict, check:comment-hygiene, check:source-conventions, check:client-boundary, check:test-patterns, check:file-names, check:boundaries, check:utils, block registry check, lint
• Full bun run test, check:audits and type-check left to CI

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Nov 1, 2026 7:26pm UTC

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; both previous findings are fixed and no new blocking issue was found.

Summary

Public shares now stream stored files beyond the 100 MB buffered limit and support byte-range requests. Pages, generated documents, and image previews keep the buffered path.

• Public share links stream stored files and serve byte ranges.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Authorize share and check file] --> B{Serve stored bytes?}
  B -->|Yes, without preview| C[Read storage size and version]
  C --> D[Build full or ranged response]
  D --> E[Open stream]
  E --> F[Recheck share, revision, and secret provenance]
  F --> G[Record delivery and audit]
  G --> H[Return stream]
  B -->|No| I[Build buffered content]
  I --> J[Recheck access and dependencies]
  J --> K[Record delivery and return buffer]

Loading

_{Reviews (2) · Last reviewed commit: "fix(public-shares): size a streamed shar..." · Reviewed by Greptile}

[cubic-dev-ai]

All reported issues were addressed across 4 files

<sub>Reply with feedback, questions, or to request a fix.

Turn on auto-fix | Re-trigger cubic</sub>

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 5 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}