[$250] Attachment - Unexpected error appears when uploading an image large than 25 MB

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.52-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-16048/folder/13176710/41236948/1304116948?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 15.4.1 Safari/Chrome, iPhone 13 iOS 26.3.1 Safari/Chrome
App Component: Chat Report View

Action Performed:

1. Go to https://staging.new.expensify.com
2. On a conversation, click on the + button in the compose box
3. Click on add attachment
4. Attempt to upload an attachment that is larger than the 24 MB limit

Expected Result:

The app automatically rejects the image to be lower than 24MB or dimensions are too large to process and should remain responsive and allow the user to continue using it normally.

Actual Result:

Unexpected error appears when uploading an image large than 25 MB

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7120784_1775227105381.Recording__1943.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @FitseTLT

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022040086187787012792
• Upwork Job ID: 2040086187787012792
• Last Price Increase: 2026-04-17

[MelvinBot]

Proposal

What is the root cause of that problem?

Client-side file size validation in validateAttachmentFile.ts:34 explicitly skips image files via the !isImage condition:

if (!isImage && !hasHeicOrHeifExtension(file) && file.size > maxFileSize)

This exclusion exists to support receipt images (which get resized in a separate step), but when uploading a regular attachment (not a receipt), there is no resize step. The oversized image passes client validation, gets sent to the server, the server rejects it, and the generic failureData in Report/index.ts:864 shows "Unexpected error posting the comment" instead of the proper "Attachment size is larger than 24 MB limit" message (which already exists in en.ts:607).

What changes do you think we should make in order to solve the problem?

In validateAttachmentFile.ts, update the size check so that image files are also validated against MAX_SIZE when NOT validating receipts. The !isImage exclusion should only apply when isValidatingReceipts is true (since receipt images get resized downstream). The condition should become something like:

if ((!isImage || !isValidatingReceipts) && !hasHeicOrHeifExtension(file) && file.size > maxFileSize)

This way, oversized images uploaded as regular attachments are caught client-side and the existing user-friendly error ("Attachment size is larger than 24 MB limit") is shown via the FILE_TOO_LARGE validation error path — no server round-trip needed.

What alternative solutions did you explore? (Optional)

An alternative would be to parse the server error response in the failureData handler to show a size-specific error message. However, client-side validation is preferable because it gives instant feedback, avoids an unnecessary network upload of a large file, and reuses the existing validation/error infrastructure.

Investigation details

Data flow of the bug:

1. User clicks + → add attachment → selects a >24 MB image
2. useAttachmentUploadValidation calls validateAttachmentFile() with isValidatingReceipts: false
3. The size check is skipped because !isImage is false
4. Image passes validation → user confirms in modal → addAttachmentWithComment() sends to server
5. Server rejects the file → failureData applies generic error: "Unexpected error posting the comment"

Key files:

• src/libs/validateAttachmentFile.ts:34 — size check skips images
• src/hooks/useFilesValidation.tsx:169-172 — resize fallback only for receipts
• src/pages/inbox/report/ReportActionCompose/useAttachmentUploadValidation.ts:180-181 — compose path sets isValidatingReceipts: false
• src/libs/actions/Report/index.ts:864 — generic failure message
• src/CONST/index.ts:288-290 — MAX_SIZE: 25165824 (24 MB)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @FitseTLT (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022040086187787012792

[trasnake87]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user uploads an image attachment larger than 24 MB in a chat conversation, the app shows a generic "Unexpected error posting the comment" message instead of the proper file-size-limit error modal.

What is the root cause of that problem?

The useFilesValidation hook at src/hooks/useFilesValidation.tsx#L160-L167 blindly trusts the isValid: true result from validateAttachmentFile for image files without performing its own size guard for the non-receipt attachment flow. Since validateAttachmentFile intentionally skips size checks on images (to allow receipt resizing downstream), useFilesValidation must enforce the size limit itself when it knows no resize step will follow — i.e., when isValidatingReceipts is false. Without this guard, the oversized image sails through validation, gets sent to the server, and is rejected with a generic failure message.

What changes do you think we should make in order to solve the problem?

In src/hooks/useFilesValidation.tsx, inside the validateAndResizeFiles loop, add a size check for images that passed validation when we are NOT in receipt mode. This ensures the user sees the proper "file too large" error modal before any upload is attempted:

// Inside the Promise.all at ~line 160
if (result.isValid) {
    // Images skip size validation in validateAttachmentFile (for receipt resizing),
    // so enforce the limit here when not validating receipts.
    if (!validationState.isValidatingReceipts && isImageFile(result.file) && result.file.size && result.file.size > CONST.API_ATTACHMENT_VALIDATIONS.MAX_SIZE) {
        collectedErrors.current.push({
            error: CONST.FILE_VALIDATION_ERRORS.FILE_TOO_LARGE,
            isValidatingMultipleFiles: validationState.isValidatingMultipleFiles,
        });
        return;
    }
    if (Str.isPDF(result.file.name ?? '')) {
        pdfsToLoad.push(result.file);
    } else {
        validNonPdfFiles.push(result.file);
    }
    return;
}

This keeps validateAttachmentFile untouched (preserving the receipt-resizing path) and catches oversized images at the orchestration layer where we already have full context about whether resizing will happen.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @KJ21-ENG Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.