[Due for payment 2026-04-20] [$250] Expense -No error modal when sending a specific attachment via the receipt button

[nlemma]

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.41-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84497 (comment)
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 15.4.1 Safari/Chrome
App Component: Money Requests

Action Performed:

1. Navigate to staging.new.expensify.com.
2. Open a workspace chat.
3. Create an expense with a receipt.
4. Open the created expense.
5. Hover over the receipt.
6. Click the Add button.
7. Upload an attachment larger than 25 MB.

Expected Result:

An error modal will appear indicating that the error exceeds the allowed size.

Actual Result:

An error "Unexpected error posting the comment. Please try again later." appers when sending an attachment larger than 25 MB from receipt button

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7108251_1774010365235.Recording__1878.mp4

Attachment - https://platform.applause.com/services/links/v1/external/85f57408ac40487b8249d2136d77ba3889c0d5d42355f571c8a62f0ab71f17c8

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034994175210436466
• Upwork Job ID: 2034994175210436466
• Last Price Increase: 2026-03-20

[MelvinBot]

Proposal

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

When a user opens an expense with a receipt, hovers over the receipt, clicks the "Add" button, and uploads an image file larger than 24 MB, they see the generic error "Unexpected error posting the comment. Please try again later." instead of a proper file-size error modal ("Attachment is too large").

What is the root cause of that problem?

The file size validation in validateAttachmentFile.ts:34 explicitly skips the size check for image files:

if (!isImage && !hasHeicOrHeifExtension(file) && file.size > maxFileSize) {
    return {isValid: false, error: CONST.FILE_VALIDATION_ERRORS.FILE_TOO_LARGE};
}

The !isImage condition means any JPG/PNG/GIF file passes validation regardless of size. When the "Add" button on a receipt (MoneyRequestReceiptView.tsx:538) calls validateFiles(files), a 50 MB image passes client-side validation, gets sent to the server via addAttachmentWithComment, and the server rejects it. The failure handler at Report/index.ts:910 then surfaces the generic genericAddCommentFailureMessage error.

There is also dead code in useFilesValidation.tsx:169 that was intended to resize oversized receipt images, but it only triggers when validateAttachmentFile returns FILE_TOO_LARGE — which never happens for images due to the skipped check.

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

In src/libs/validateAttachmentFile.ts, remove the !isImage guard from the size check on line 34 so that images are also validated against the file size limit:

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

should become:

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

This way, oversized images will return FILE_TOO_LARGE, which will:

1. Show the proper "Attachment is too large" error modal for standard attachment uploads
2. Enable the existing resize logic in useFilesValidation.tsx:169 for receipt uploads (where isValidatingReceipts=true), so oversized receipt images get resized instead of rejected

HEIC/HEIF images are already handled separately on line 28-30, so the !hasHeicOrHeifExtension guard should remain.

What alternative solutions did you explore? (Optional)

An alternative would be to add a separate size check specifically for the receipt "Add" button path before calling addAttachmentWithComment. However, this would duplicate validation logic and wouldn't fix the same issue that also exists in the chat composer attachment path. The proposed fix addresses both paths at the source.

---

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 - @dukenv0307 (External)

[melvin-bot]

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

[twilight2294]

Proposal

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

When a user opens an expense with a receipt, hovers over the receipt, clicks the "Add" button, and uploads an oversized image, they see a generic "Unexpected error posting the comment" instead of a proper file-size error modal.

What is the root cause of that problem?

The "Add" button on an existing receipt routes the uploaded file through the comment attachment flow instead of the receipt replacement flow. In MoneyRequestReceiptView, the onAttachmentFilesValidated callback calls addAttachmentWithComment(), posting the file as a chat comment rather than replacing the receipt. The useFilesValidation hook on line 208 is wired to this wrong callback.

However, the correct callback already exists in the same file — setReceiptFile() at MoneyRequestReceiptView calls replaceReceipt(), which is the proper receipt replacement path. We can confirm this is the intended pattern because ReceiptEmptyState correctly passes setReceiptFile to useFilesValidation.

So when a large image is uploaded via the "Add" button: it passes client-side validation (since validateAttachmentFile skips size checks for images), gets sent as a comment attachment to the API, the API rejects it, and the generic comment-failure error surfaces instead of a receipt-specific error.

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

In MoneyRequestReceiptView, change the useFilesValidation call to use setReceiptFile instead of onAttachmentFilesValidated, and remove the now-unused onAttachmentFilesValidated function and the addAttachmentWithComment import:

- const {validateFiles, PDFValidationComponent, ErrorModal: AttachmentErrorModal} = useFilesValidation(onAttachmentFilesValidated);
+ const {validateFiles, PDFValidationComponent, ErrorModal: AttachmentErrorModal} = useFilesValidation(setReceiptFile);

Since setReceiptFile is defined later in the component, move the useFilesValidation call to after the setReceiptFile definition, or use a ref-based stable callback to avoid hook ordering issues.

This ensures the "Add" button on an existing receipt correctly triggers replaceReceipt() — matching the pattern already used by the empty receipt state — so oversized files are handled through the proper receipt flow with appropriate error feedback.

What alternative solutions did you explore? (Optional)

The existing proposal suggests removing the !isImage guard from the size check in validateAttachmentFile. While that would surface the FILE_TOO_LARGE error earlier, it changes validation behavior for all image uploads across the entire app, not just receipts. The real bug is that the "Add" receipt button is wired to the wrong handler — it posts a comment instead of replacing the receipt. Fixing the callback routing is more targeted: it solves the problem at its source without altering global image validation semantics, and it also fixes any other receipt-specific handling (like the resize logic in useFilesValidation) that was being bypassed by going through the comment path.

[shivang-goliyan]

Proposal

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

When a user opens an expense with a receipt, clicks the "Add" button, and uploads a file larger than 24MB, they see a generic "Unexpected error posting the comment" instead of a proper file-size error modal. The oversized file reaches the server unvalidated, and the server rejection surfaces as a confusing generic message.

What is the root cause of that problem?

The "Add" button in MoneyRequestReceiptView.tsx (lines 480-515) uses AttachmentPicker directly and passes picked files straight to addAttachmentWithComment() with zero client-side validation. AttachmentPicker itself (AttachmentPicker/index.tsx:53-80) is just a hidden <input type="file"> — it performs no size, type, or corruption checks.

Every other file upload path in the app routes through the useFilesValidation hook before sending files to the API. ReceiptEmptyState.tsx:63 does it, useAttachmentUploadValidation.ts:134 does it. The "Add" button is the only upload path that skips validation entirely.

This was introduced in commit 63e60600c29 ("Allow Multiple Receipts to Be Attached to a Single Expense") — the feature was new and validation was simply never wired up. Subsequent commits refined styling and hover behavior but never addressed the gap. The existing test file (MoneyRequestReceiptViewTest.tsx) covers button visibility but has no coverage for the file validation path.

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

Add useFilesValidation to MoneyRequestReceiptView.tsx, following the identical pattern already used by ReceiptEmptyState.tsx:63:

1. Create a callback that wraps the existing addAttachmentWithComment() call
2. Initialize the hook: const {validateFiles, PDFValidationComponent, ErrorModal} = useFilesValidation(onAttachmentValidated)
3. Change the onPicked handler from calling addAttachmentWithComment() directly to calling validateFiles(files, [], {isValidatingReceipts: false})
4. Render {PDFValidationComponent} and {ErrorModal} in the component's JSX

Using isValidatingReceipts: false because the Add button accepts any file type and posts as a general attachment — the relevant limit is 24MB (MAX_SIZE), not 10MB (RECEIPT_MAX_SIZE). For oversized images, useFilesValidation will automatically resize them instead of rejecting (lines 228-276), which is strictly better UX. For oversized non-image files, the proper "File too large" error modal appears.

What alternative solutions did you explore? (Optional)

Removing the !isImage guard from the size check in FileUtils.ts:690 (as MelvinBot suggested) doesn't help here — the Add button never calls validateAttachment in the first place, so changing that function's logic has no effect on this code path. It would also break the intended resize-instead-of-reject behavior for images globally.

Changing the callback from addAttachmentWithComment to replaceReceipt would alter the button's functionality from "add attachment" to "replace receipt," which contradicts the feature's intent per commit 63e60600c29. The issue isn't which API call is made — it's that no validation happens before any API call is made.

[TaduJR]

@cristipaval

Assignment here also

Thanks!

[nkdengineer]

Proposal

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

An error "Unexpected error posting the comment. Please try again later." appers when sending an attachment larger than 25 MB from receipt button

What is the root cause of that problem?

We skipped the maxSize check for the image, which caused two problems:

App/src/libs/validateAttachmentFile.ts

Lines 34 to 38 in 7015231

	if (!isImage && !hasHeicOrHeifExtension(file) && file.size > maxFileSize) {
	return {isValid: false, error: CONST.FILE_VALIDATION_ERRORS.FILE_TOO_LARGE};
	}
	if (isValidatingReceipts && file.size < CONST.API_ATTACHMENT_VALIDATIONS.MIN_SIZE) {

1. The too-large-file validation for normal attachment is skipped, which caused the error in this issue.
2. The resize receipt image logic is skipped here, as the result never returns the max size error for the image

App/src/hooks/useFilesValidation.tsx

Lines 169 to 175 in 7015231

	if (result.error === CONST.FILE_VALIDATION_ERRORS.FILE_TOO_LARGE && isImageFile(file) && validationState.isValidatingReceipts) {
	filesToResize.push(file);
	return;
	}
	if (result.error === CONST.FILE_VALIDATION_ERRORS.HEIC_OR_HEIF_IMAGE) {
	filesToConvert.push(file);

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

It is expected that we will call addAttachmentWithComment to add the attachment as a comment here when adding via the Add button in the receipt.

1. We should remove !isImage check here. Since !isImage is unnecessary here and we returned early below with hasHeicOrHeifExtension(file) check, we can also remove !hasHeicOrHeifExtension(file) check

App/src/libs/validateAttachmentFile.ts

Lines 34 to 38 in 7015231

	if (!isImage && !hasHeicOrHeifExtension(file) && file.size > maxFileSize) {
	return {isValid: false, error: CONST.FILE_VALIDATION_ERRORS.FILE_TOO_LARGE};
	}
	if (isValidatingReceipts && file.size < CONST.API_ATTACHMENT_VALIDATIONS.MIN_SIZE) {

2. After fixing this problem, we will see the error attachment size is larger than 10MB

The reason is isImageFile check here always returns the first part hasHeicOrHeifExtension(file) which is false. So to apply the resize logic, we need to fix this function by using || operator instead of ??

const isImageFile = (file: FileObject) => hasHeicOrHeifExtension(file) || Str.isImage(file.name ?? '');

App/src/hooks/useFilesValidation.tsx

Line 35 in 7015231

const isImageFile = (file: FileObject) => hasHeicOrHeifExtension(file) ?? Str.isImage(file.name ?? '');

What alternative solutions did you explore? (Optional)

An error "Unexpected error posting the comment. Please try again later." appers when sending an attachment larger than 25 MB from receipt button

For point 2, if we want to validate the file as a normal attachment with size limit 24MB, we can pass isValidatingReceipts option as false here

validateFiles(files, undefined, {isValidatingReceipts: false});

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Line 538 in 6d289e3

validateFiles(files);

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

⚠️ @nkdengineer 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.