fix(files): bound the HEIF fallback decode input

[waleedlatif1]

Summary

Follow-up to #6346, which merged before this commit landed on the branch — the HEIF decoder went out without an input bound.

Nothing upstream capped what could reach the WebAssembly decoder: uploads allow 100MB (validation.ts:15) and prepareImageForVision runs sharp with limitInputPixels: false. A tenant-controlled file could therefore spend unbounded CPU and memory on a single-threaded decode during one copilot read.

transcodeHeicToJpeg now refuses input above a 20MB ceiling and returns null, which the existing "[Image unavailable]" path already handles. 20MB leaves generous headroom over any phone photo — a 12MP iPhone HEIC runs 1-4MB.

Scope — what this does and does not cover

• Bounds file size. A large HEIF no longer reaches the decoder at all.
• Does not bound pixel count. A small file declaring enormous dimensions is a separate vector. It stays bounded by libheif's own security limits during parse, which are demonstrably active: the sharp attempt on a real iPhone HEIC fails with libheif's Security limit exceeded before any decode happens.
• No timeout or cancellation on the decode itself; the byte ceiling is what bounds its duration.

Raised by Greptile on #6346 and worth disagreeing with if 20MB or the pixel-vector reasoning looks wrong.

Type of Change

• Bug fix

Testing

Added a test asserting input above the ceiling returns null without invoking the decoder. 19 tests, typecheck clean.

Checklist

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

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Aug 6, 2026 11:01pm

[cursor]

PR Summary

Low Risk
Small, defensive guard on an existing fallback path; failure mode matches prior decode failures and does not change auth or data handling.

Overview
Adds a 20MB input ceiling on transcodeHeicToJpeg so tenant uploads (up to 100MB) cannot force unbounded CPU/memory on the single-threaded heic-convert WASM path during copilot file reads.

Oversized buffers are rejected before the dynamic import/decode, logged with a warning, and return null—the same outcome the VFS image reader already treats as "[Image unavailable]" when transcode fails.

A unit test asserts buffers above 20 * 1024 * 1024 bytes return null without invoking the decoder.

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

[greptile-apps]

Greptile Summary

The PR prevents oversized HEIF files from reaching the WebAssembly fallback decoder.

• Adds a 20 MiB input ceiling before dynamically importing or invoking heic-convert.
• Returns null through the existing unavailable-image path and logs rejected input sizes.
• Adds a boundary test for input exceeding the ceiling.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

The input guard executes before decoder loading, and the sole caller already converts a null result into the intended unavailable-image response.

Important Files Changed

Filename	Overview
apps/sim/lib/uploads/server/heic.ts	Adds an early 20 MiB guard that safely follows the helper's existing nullable contract and avoids invoking the decoder.
apps/sim/lib/uploads/server/heic.test.ts	Verifies that input one byte above the ceiling is rejected with null.

_{Reviews (1): Last reviewed commit: "fix(files): bound the HEIF fallback deco..." | Re-trigger Greptile}