Scan - User directed to create expense page after capturing multiple receipt via scan icon

[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: V9.3.32-0
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/test-runs/TR-7763/folder/13176932/41237693/1232119333
Email or phone of affected tester (no customers): dreamnitethedragon+yydyd373@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redminote 10S Android 13
App Component: User Settings

Action Performed:

1. Launch app
2. Tap scan icon ( green camera icon)
3. Tap multiple scan receipt icon
4. Capture few images and tap side arrow
   5.select a user

Expected Result:

User must be able to create expense after capturing multiple receipt via scan icon.

Actual Result:

User directed to create expense page after capturing multiple receipt via scan icon.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @trjExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @neil-marcellini (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: #83470 - "Scan Receipt UX/perf improvements" by @marcaaron (High confidence)
Related Issues: #83469 (the issue that PR #83470 was fixing)

Recommendation: REVERT

PR #83470 introduced significant changes to the receipt scanning camera flow, including freezing the camera on capture and refactoring the capture state management. The changes are extensive and affect critical timing-sensitive code paths in the multi-scan receipt flow. A revert is the safest approach to unblock the deploy while the issue is investigated and fixed properly.

Labels: Keeping DeployBlockerCash label (App deploy is blocked due to frontend bug)

Detailed Analysis

Evidence

PR #83470 was merged on March 3, 2026 and modified the scan receipt camera implementation (src/pages/iou/request/step/IOURequestStepScan/index.native.tsx). The PR made several changes:

1. Added camera freezing on capture (forceInactive={isAttachmentPickerActive || didCapturePhoto})
2. Refactored capture state from didCapturePhoto to isCapturingPhoto.current ref for double-tap protection
3. Removed image cropping from the native capture path
4. Pre-created upload directory during initialization

The issue affects the multi-scan receipt flow specifically on Android native, which is the primary platform modified by this PR.

Verification

Confirmed that PR #83470:

• Modified src/pages/iou/request/step/IOURequestStepScan/index.native.tsx (85 additions, 83 deletions)
• Merged to main on March 3, 2026 at 21:19:05 UTC
• Is included in staging (commit 245e40a is on staging branch)
• Affects the scan receipt camera behavior on Android native (the reported platform)

Root Cause

The PR changed how camera state is managed during photo capture. Specifically:

• Line 375: setDidCapturePhoto(true) is called after photo capture
• Line 505: Camera becomes inactive when didCapturePhoto is true via forceInactive prop
• Lines 407-410: In multi-scan mode, state is reset with setDidCapturePhoto(false) and isCapturingPhoto.current = false

There appears to be a timing issue or state synchronization problem in the multi-scan flow where the camera state changes and navigation logic may not work correctly after capturing multiple receipts. The refactoring from state to ref for capture protection and the addition of camera freezing likely introduced an edge case in the multi-scan user flow.