Expense - Confirm page loads infinitely after switching from Scan to Manual tab

[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.74-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87920
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Run Onyx.merge('betas', ['newManualExpenseFlow']); in console.

1. Go to staging.new.expensify.com
2. Create a new account.
3. Create a new workspace.
4. Open FAB > Create expense.
5. Switch to Manual tab.

Expected Result:

Confirm page will not load infinitely.

Actual Result:

Confirm page loads infinitely after switching from Scan to Manual tab.

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]

You have been assigned to this deploy blocker because you recently merged this PR: #87920

[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: #87920 - "Feat: Manual expense flow UI refactor - r3" by @ChavdaSachin (High confidence)
Related Issues: None

Recommendation: REVERT

PR #87920 introduced the new manual expense flow (newManualExpenseFlow beta). The confirm page loading infinitely is a direct regression from this PR's changes, and reverting it is the cleanest path to unblocking the deploy.

Assigned: @ChavdaSachin (PR author), @ShridharGoel @puneetlath (approving reviewers)
Labels: DeployBlockerCash kept (Frontend bug in App). No label changes made.

Detailed Analysis

Evidence

• The bug is only reproducible on staging (new feature, not in production), which matches PR Feat: Manual expense flow UI refactor - r3 #87920 being in the current staging deploy (StagingDeployCash checklist PR Deploy Checklist: New Expensify 2026-05-13 #90562).
• The bug requires the newManualExpenseFlow beta flag to reproduce, which is the exact feature this PR implements.
• The melvin-bot already linked this PR to the issue.
• The PR was merged on 2026-05-13 and is listed in the staging deploy checklist.

Verification

• Affected files: src/pages/iou/request/step/IOURequestStepConfirmation.tsx and src/pages/iou/request/IOURequestStartPage.tsx — both are listed in the PR's changed files.
• Key change in PR: When the newManualExpenseFlow beta is enabled, IOURequestStepConfirmation is now embedded directly inside the Manual tab of IOURequestStartPage (lines 251-256 of IOURequestStartPage.tsx).

Root Cause

In IOURequestStepConfirmation.tsx at line 757, there is a condition that renders a FullScreenLoadingIndicator:

{(isLoading || (isScanRequest(transaction) && !Object.values(receiptFiles).length)) && (
    <FullScreenLoadingIndicator ... />
)}

When the user starts on the Scan tab, the draft transaction's iouRequestType is set to CONST.IOU.REQUEST_TYPE.SCAN. When they switch to the Manual tab, IOURequestStepConfirmation is rendered (because of the new embedded flow), but:

1. isScanRequest(transaction) returns true because the transaction's iouRequestType is still SCAN — initMoneyRequest (called via resetIOUTypeIfChanged in useResetIOUType) is triggered asynchronously via Onyx and may not have updated yet, or does not update the embedded component's transaction reference in time.
2. Object.values(receiptFiles).length is 0 because no receipt has been provided in the manual flow.

The combination causes the loading indicator to show indefinitely. In the original (non-embedded) confirmation flow this was not an issue because the confirmation page was never reached with a SCAN request type and no receipt. The new embedded architecture in PR #87920 created this edge case.

[ShridharGoel]

This is a known bug and is behind beta.