Scan - App returns to scan page when tapping on any field in confirmation page

[applause-bot]

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.91-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-37255/folder/13176676/41237305/1455623924?sort=%2Bidentifier
Email or phone of affected tester (no customers): htad26+etreio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 13/iOS 26.5
App Component: Money Requests

Action Performed:

1. Navigate to a workspace chat
2. Tap on + icon > Create expense > Scan
3. Take a picture or choose any file
4. In the confirmation page tap on any field (e.g Description, Category, tags)

Expected Result:

User is taken to the next page

Actual Result:

App returns to create scan page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169367_1780387358782.video_2026-06-02_11-02-12.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7169367

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/f048da90e6f4c80e56fe1c078f9358c84fafd9267e2a0f1ecc9aef1707088943

[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.

[MelvinBot]

Proposal

Root-cause location is high confidence; the exact regressing PR still needs a native device repro to confirm (see "Next steps").

What is the root cause of that problem?

On native only, the "bounce back to the scan page" is produced by ReceiptFileValidator, a side‑effect component rendered by the confirmation page. Its useEffect re‑validates the receipt file whenever its dependencies change, and on a validation failure for a scan request it calls navigateToStartMoneyRequestStep → Navigation.goBack(ROUTES.MONEY_REQUEST_CREATE_TAB_SCAN…). goBack pops the stack to the scan create tab — which is exactly the observed symptom (a backward pop, not a wrong forward push).

Why it's native‑only: validateReceiptFile has a platform split. The native variant validates via checkFileExists → RNFS.stat, whereas web uses a different check. So a validation failure that triggers the redirect can only happen on iOS/Android App, matching the reported platforms.

The field menu items themselves are not the cause — Description/Category/Tag correctly call forward Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_*). The backward navigation is the validator's effect re‑firing in response to the navigation/re‑render (its deps include transactions and participants, which get fresh references on render) and then failing the native file check.

Evidence & the one open question

• Forward (correct) field navigation: DescriptionField.tsx:130‑132, CategoryField.tsx:97, TagFields.tsx:69.
• Validator deps include transactions/participants: ReceiptFileValidator.tsx:137. transactions (from useOptimisticDraftTransactions) and the participants memo both return new array references on render, so an incidental Onyx tick after the tap re‑fires the effect.
• The step pages' guards (withFullTransactionOrNotFound, etc.) render a NotFound page and do not redirect to scan — ruled out.
• Open question (needs device confirmation): if the receipt file were genuinely missing, the page would bounce on mount, not on field tap. So either the receipt source is being made unresolvable around navigation, or the native RNFS.stat check is returning a false negative on re‑validation. Confirming this on a device is the key to the precise fix.

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

Make ReceiptFileValidator non‑destructive on spurious re‑runs: the redirect to the scan step should only fire on the initial receipt check (e.g. when the page first mounts / the receipt is genuinely unreadable), not every time the effect re‑runs due to transactions/participants reference churn during in‑flow navigation. Concretely: gate the navigateToStartMoneyRequestStep / goBack(SCAN) branch behind a "first validation only" ref (or skip it once a receipt has already validated successfully for that transaction), and/or stabilize the effect's dependencies so it doesn't re‑fire when the user merely opens a field editor.

For the deploy block specifically, the fastest path is to identify and revert the regressing PR once reproduced on a device (candidates in the details below), then land the validator hardening as the durable fix.

Regression candidates to bisect (timing: on staging v9.3.91‑0, not in production)

• #88055 "refactor: Remove shouldHandleNavigation from requestMoney and trackExpense" (TaduJR, merged 2026‑06‑01 ~3h before the staging build). Large navigation refactor touching IOURequestStepConfirmation.tsx, ScanRouter.tsx, and confirmation submit/cleanup helpers. Best timing/scope match, but it did not touch ReceiptFileValidator/IOUUtils, so if it's the cause it's via the validator's inputs, not the validator itself.
• #90445 "[Odometer] Fix race condition" (merged 2026‑05‑27) — the most recent change to ReceiptFileValidator itself (hoisted the isReceiptReady guard).

A git bisect between the last production cut and v9.3.91‑0 on a native device, focused on these, will isolate it quickly.

What alternative solutions did you explore? (Optional)

Verified it is not the field menu items (they navigate forward correctly) and not the step‑page guards (they render NotFound, never redirect to scan). The narrow‑layout preInsertFullscreenUnderRHP effect was also considered but handles post‑submit landing, not field‑tap, so it doesn't fit.

Next steps

• Reproduce on an iOS/Android device with logging in ReceiptFileValidator's effect (count re‑runs per tap) and on RNFS.stat (log the receipt.source value + stat result) to confirm whether the file is genuinely missing or the check is a false negative.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92341) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.