Web - User receives an error message while scanning a receipt. The expense is not created.

[jponikarchuk]

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: 9.3.40-4
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176925/test-cases/41237598
Email or phone of affected tester (no customers): fischer9966+notif@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacOS 26.3.1 / Chrome, Safari
App Component: Money Requests

Action Performed:

1. Login to staging.new.expensify.com with any account
2. Go to any 1:1 chat
3. Click + > Create expense
4. Click "Choose files" and select receipt from computer
5. Click "Create expense"

Expected Result:

Expense is created from receipt image from computer

Actual Result:

User receives an error message while scanning a receipt image from computer. The expense is not created.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @mjasikowski (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #70740 - "refactor: Improve and simplify attachment and file validation" by @chrispader (High confidence)
Related Issues: None found

Recommendation: REVERT

PR #70740 introduced a memory leak in the receipt upload flow that causes scanning to fail. The PR should be reverted to unblock the deploy.

Labels: This is a frontend bug (App PR caused the issue). Keeping DeployBlockerCash label as appropriate. The DeployBlocker label should be removed if present since this is not a backend issue.

Detailed Analysis

Evidence

PR #70740 was merged on 2026-03-18 12:16:24 UTC and is in the current staging deploy (9.3.40-4). The issue only reproduces on staging (not production), which aligns with this PR being newly deployed to staging.

The PR refactored attachment validation by introducing a new file src/libs/validateAttachmentFile.ts. This file contains logic that creates object URLs for uploaded files.

Verification

I examined the receipt upload flow and found the following files are involved:

• src/pages/iou/request/step/IOURequestStepScan/components/DesktopWebUploadView.tsx - Handles file upload UI
• src/libs/validateAttachmentFile.ts - New file added in PR refactor: Improve and simplify attachment and file validation #70740 that validates attachments

Both files create object URLs for the same file, causing a double allocation.

Root Cause

When a user uploads a receipt from their computer on web:

1. DesktopWebUploadView.tsx line 63 creates an object URL:

   file.uri = URL.createObjectURL(file);

2. The file is then passed to validation, which calls the new validateAttachmentFile.ts

3. validateAttachmentFile.ts line 73-74 creates a SECOND object URL and overwrites the first:

   const inputSource = URL.createObjectURL(updatedFile);
   updatedFile.uri = inputSource;

4. The first object URL is never revoked with URL.revokeObjectURL(), causing a memory leak

5. When the browser runs out of memory for blob URLs, the receipt scan fails with an error

This is a classic object URL memory leak. Each createObjectURL allocates memory in the browser that must be manually freed with revokeObjectURL. By creating two URLs but only using the second one, the first leaks memory.

[MelvinBot]

Proposal

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

When creating an expense from a 1:1 chat by clicking + > Create expense > Choose files > selecting a receipt image > Create expense, the user receives an error message and the expense is not created. This is reproducible on staging (v9.3.40-4) but not production.

What is the root cause of that problem?

Causing PR: #70740 — "refactor: Improve and simplify attachment and file validation"

This PR refactored the entire attachment/file validation pipeline (useFilesValidation.tsx, new validateAttachmentFile.ts, AttachmentUtils.ts, FileUtils.ts), which is the exact code path receipts go through when uploaded from a file picker on web. Two related deploy blockers confirm PR #70740 as the source:

• #85671 — "No content to add" error when uploading attachments — was caught during QA of PR refactor: Improve and simplify attachment and file validation #70740 itself
• #85669 — "Uploaded receipt is not displayed when create manual expense" — independently traced to the same PR

The specific code issues introduced by PR #70740:

1. ?? vs || bug in isImageFile at src/hooks/useFilesValidation.tsx:35:

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

   hasHeicOrHeifExtension returns false (not null/undefined) for JPG/PNG files. The ?? (nullish coalescing) operator only falls through for null/undefined, NOT false. So false ?? Str.isImage(...) evaluates to false. This means all non-HEIC images are misidentified as non-images, making the resize-on-error path dead code for standard receipt photos (JPG, PNG).

2. Images bypass the size check in validateAttachmentFile.ts:32-35:

   const isImage = Str.isImage(file.name);
   if (!isImage && !hasHeicOrHeifExtension(file) && file.size > maxFileSize) {
       return {isValid: false, error: FILE_TOO_LARGE};
   }

   The !isImage condition means recognized images never get FILE_TOO_LARGE, so they pass validation regardless of size. Combined with bug Some initial fixes and code style updates #1, large images that previously got resized now go directly to upload at full size, potentially causing server-side rejection.

3. New FILE_INVALID early-exit check at validateAttachmentFile.ts:20-22:

   if (!file.name || file.size == null) {
       return {isValid: false, error: CONST.FILE_VALIDATION_ERRORS.FILE_INVALID};
   }

   This check did not exist in the old code. While standard browser File objects always have name and size, edge cases with custom FileObject wrappers could be silently rejected.

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

A revert PR is already open: #85752 — "Revert: refactor: Improve and simplify attachment and file validation". This should be merged to unblock the deploy.

If a targeted fix is preferred instead of a full revert, the minimum change is at src/hooks/useFilesValidation.tsx line 35 — change ?? to ||:

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

What alternative solutions did you explore? (Optional)

The ?? to || fix addresses the isImageFile bug but may not fix all issues introduced by the broader refactor (the "No content to add" error from #85671 may have a separate mechanism within the same PR). The full revert via #85752 is the safer option for unblocking the deploy.

---

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.