fix(tools): bound download response size for drive/slack/onedrive

[waleedlatif1]

Summary

• Google Drive, Slack, and OneDrive download tool routes fetched provider file content without a response size cap, unlike the SharePoint download route which already bounds it.
• Add maxResponseBytes: MAX_FILE_SIZE to every content-download secureFetchWithPinnedIP call in these three routes (metadata fetches are small JSON and unaffected).
• For Google Drive, reject the direct-download path early using the file size already present in the fetched metadata, before initiating content download (Workspace-native exports skip this check since their metadata doesn't carry a byte size).
• Map the resulting size-limit error to a clean 413 in each route's catch block, matching the existing pattern in google_slides/export-presentation.

Test plan

• Added route.test.ts for all three routes: normal file under cap succeeds, oversized streamed response returns 413, Google Drive oversized metadata size is rejected before content fetch, Google Workspace exports proceed without a metadata size.
• bun run vitest run on all three new test files — 8/8 pass
• bun run type-check
• bunx biome check
• bun run check:api-validation

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jul 4, 2026 7:03pm

[cursor]

PR Summary

Low Risk
Defensive size limits on authenticated tool downloads; behavior change is rejecting oversized files that could previously exhaust memory, with tests covering the new paths.

Overview
Google Drive, OneDrive, and Slack download tool routes now cap provider content fetches with maxResponseBytes: MAX_FILE_SIZE on secureFetchWithPinnedIP, matching the pattern already used elsewhere (e.g. SharePoint). Small metadata JSON calls are unchanged.

Google Drive additionally rejects regular binary downloads when Drive metadata size is already above the cap (assertKnownSizeWithinLimit) so the content request is never started; Workspace export paths still export without that metadata check but still stream with the same byte limit.

Oversized responses surface as 413 via isPayloadSizeLimitError in each route’s catch block instead of a generic 500. New Vitest route tests cover success under the cap, streamed oversize → 413, Drive metadata oversize (single fetch), and Workspace export without metadata size.

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

[greptile-apps]

Greptile Summary

This PR adds a maxResponseBytes: MAX_FILE_SIZE cap to every content-download secureFetchWithPinnedIP call in the Google Drive, Slack, and OneDrive download routes, and maps the resulting PayloadSizeLimitError to a clean 413 response in each catch block — bringing these three routes in line with the existing SharePoint pattern. For Google Drive regular files, it also adds an early-rejection pre-flight check using the file size already present in metadata, avoiding any bandwidth spend for known-oversized files.

• Google Drive: Pre-flight assertKnownSizeWithinLimit on metadata.size before initiating the download fetch (skipped for Workspace exports that don't carry a byte size in metadata); maxResponseBytes added to both the export and download secureFetchWithPinnedIP calls; catch block upgraded to return 413 on PayloadSizeLimitError.
• Slack and OneDrive: maxResponseBytes: MAX_FILE_SIZE added to the single content-download secureFetchWithPinnedIP call in each route; catch block upgraded to return 413 on PayloadSizeLimitError.
• Tests: New route.test.ts for all three routes covering the under-cap success path, the stream-limit 413 path, and (for Google Drive) the metadata pre-flight rejection path and the Workspace-export bypass.

Confidence Score: 5/5

Safe to merge — the change is a narrow, additive guard that applies a consistent size-bounding pattern to three previously unbounded download routes.

All three routes receive the same treatment used by SharePoint: a stream-size cap on the content fetch and a 413 mapping in the catch block. Google Drive additionally gains a metadata-driven pre-flight check that stops the download before any bytes are transferred. The logic is straightforward, the helpers are well-tested shared utilities, and the new test files exercise the key paths. No regressions are introduced on the success path.

No files require special attention. All three route files and their corresponding tests are consistent and correct.

Important Files Changed

Filename	Overview
apps/sim/app/api/tools/google_drive/download/route.ts	Adds maxResponseBytes to both export and download fetches and a pre-flight assertKnownSizeWithinLimit guard on metadata.size for regular files; catch block now returns 413 on PayloadSizeLimitError. Logic is correct and mirrors SharePoint pattern.
apps/sim/app/api/tools/onedrive/download/route.ts	Adds maxResponseBytes to the content download fetch and 413 mapping in the catch block; no pre-flight size check (metadata size field not yet included in DriveItemMetadata).
apps/sim/app/api/tools/slack/download/route.ts	Adds maxResponseBytes to the secureFetchWithPinnedIP call and 413 mapping in the catch block; the Slack files.info metadata fetch (via global fetch) is unchanged and intentionally unbounded.
apps/sim/app/api/tools/google_drive/download/route.test.ts	New test file; covers under-cap success, stream-limit 413, metadata pre-flight rejection (verifies second fetch never fires), and Workspace export bypass. All assertions are correct.
apps/sim/app/api/tools/onedrive/download/route.test.ts	New test file; covers under-cap success (with maxResponseBytes assertion) and stream-limit 413 path. Correct.
apps/sim/app/api/tools/slack/download/route.test.ts	New test file; mocks global.fetch for the files.info call and secureFetchWithPinnedIP for the download; restores global.fetch in afterEach. Covers under-cap success and stream-limit 413 path correctly.

_{Reviews (2): Last reviewed commit: "fix(tools): bound download response size..." | Re-trigger Greptile}

[waleedlatif1]

@greptile review

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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