Amount field changes to not here page after creating expense and opening it on Spend

[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.62-5
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87982
Email or phone of affected tester (no customers): sdjoisndjosjdoisjodjosd@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:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Go to Spend > All expenses.
5. Click on the expense.
6. Quickly click Amount field.

Expected Result:

Amount field will not change to not here page.

Actual Result:

Amount field changes to not here page.

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: #87982

[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: #87982 - "perf: navigate before optimistic writes in Search onSelectRow" by @adhorodyski (High confidence)
Related Issues: #87990

Recommendation: REVERT

PR #87982 reordered the navigation and optimistic state setup in Search's onSelectRow, causing the expense Amount field to navigate to a "not here" (not found) page when clicked quickly after opening from search results.

Assigned: @adhorodyski (PR author), @mananjadhav and @rlinoz (approving reviewers)
Labels: No label changes needed — DeployBlockerCash is correct (this is a frontend App repo bug, staging-only)

Detailed Analysis

Evidence

• The melvin-bot immediately flagged PR perf: navigate before optimistic writes in Search onSelectRow #87982 as the associated PR when this issue was filed.
• The issue is reproducible only on staging (version 9.3.62-5), not on production. PR perf: navigate before optimistic writes in Search onSelectRow #87982 is in the current staging deploy list (StagingDeployCash Deploy Checklist: New Expensify 2026-04-23 #88633, entry Find a way to do 'calc(100vh - 73px)' with flexbox because mobile can't use this #20 in chronological order).
• The bug is triggered by quickly clicking the Amount field after opening an expense from Search > All expenses. This is precisely the code path changed by perf: navigate before optimistic writes in Search onSelectRow #87982.

Verification

• The affected file is src/components/Search/index.tsx — the only file changed by PR perf: navigate before optimistic writes in Search onSelectRow #87982.
• The regression affects the onSelectRow flow for transaction items (non-group) in the Search component.

Root Cause

Before PR #87982, the flow was:

1. Call markReportIDAsExpense(reportID) — sets optimistic Onyx state so the report is treated as wide-RHP expense
2. requestAnimationFrame(() => Navigation.navigate(...)) — navigate after the next paint, by which time the Onyx state is ready

After PR #87982, the flow is:

1. Navigation.navigate(...) — navigate immediately
2. startTransition(() => { markReportIDAsExpense(reportID); }) — deferred as a low-priority React transition

The problem: startTransition defers the markReportIDAsExpense state update to after the navigation renders the new screen. The navigated-to screen reads the WideRHPContextProvider's expenseReportIDs set to decide how to display the report. Because markReportIDAsExpense hasn't run yet when the screen renders, the report is not recognized as an expense report. When the user quickly taps the Amount field, the screen is in an inconsistent state (navigated to the report screen but the report hasn't been marked as expense yet), causing it to resolve to a "not here" / not-found page.

The requestAnimationFrame approach in the original code ensured the optimistic Onyx/state write completed before navigation began. Replacing it with startTransition breaks this guarantee because React can delay transition updates indefinitely while the render from navigation is still in progress.

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #87982 reordered onSelectRow in Search/index.tsx:1185-1193 to navigate immediately, then defer optimistic data setup:

1. Navigation.navigate() fires first — the report screen starts mounting
2. markReportIDAsExpense is wrapped in startTransition — deferred as low-priority
3. setOptimisticDataForTransactionThreadPreview writes Onyx data (report, reportAction, transaction) after navigation — but Onyx.update is async

When the user quickly clicks the Amount field before the optimistic Onyx data has propagated, IOURequestStepAmount mounts and its guards (useShowNotFoundPageInIOUStep, withFullTransactionOrNotFound, withWritableReportOrNotFound) find that reportAction is undefined or the transaction is missing. This triggers FullPageNotFoundView with the default "not here" title.

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

Move the optimistic Onyx writes (setOptimisticDataForTransactionThreadPreview) before Navigation.navigate() so the data is available when sub-routes mount. The startTransition-wrapped markReportIDAsExpense (which only controls wide RHP display width) can stay deferred since it doesn't gate navigation guards.

The fix in src/components/Search/index.tsx onSelectRow would reorder the calls to:

1. Call setOptimisticDataForTransactionThreadPreview first (sync Onyx writes)
2. Then Navigation.navigate()
3. Then startTransition(() => markReportIDAsExpense(reportID))

This preserves the perf improvement from PR #87982 (deferring the RHP width state update) while ensuring the data guards on sub-routes have the data they need.

What alternative solutions did you explore? (Optional)

• Add loading/skeleton states to IOURequestStepAmount guards: Would prevent the "not here" page but adds UI complexity and doesn't address the core ordering issue.
• Wrap the Amount field click handler with a data-ready check: More invasive and would need to be applied to every editable field on the expense.

Investigation details

Related issue: #77179 is a similar symptom ("Amount field opens not here page") but has a different root cause (split expenses with "Done" report status). Not a duplicate.

Evidence chain:

• Navigation fires at line 1185 before any data writes
• setOptimisticDataForTransactionThreadPreview at line 1192 writes report/reportAction/transaction to Onyx after navigation
• useShowNotFoundPageInIOUStep checks isMoneyRequestAction(reportAction) — returns false when reportAction is undefined, showing the not-found page
• FullPageNotFoundView defaults to titleKey = 'notFound.notHere' — matching the reported symptom

Reproducibility: The bug is timing-dependent — users who click the Amount field quickly after the expense opens will hit it before Onyx data propagates. Slower interactions work fine because the data arrives in time.

---

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.