[Due for payment 2026-03-30] mWeb - Create Expense - “Hmm It's Not Here” page appears after deleting an expense

[lanitochka17]

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.41-3
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-11438/folder/13177029/41237799/1266499247
Email or phone of affected tester (no customers): joelarmandotester+748@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: IPhone 12 / IOS 26.3.1 / Chrome
App Component: Money Requests

Action Performed:

1. Goto staging.new.expensify.com
2. Sign in to an account
3. Go to a 1:1 DM.
4. Create two expenses.
5. Open one of those expenses.
6. Tap on "More" and delete the expense.

Expected Result:

It should redirect me to the other expense listed in the report.

Actual Result:

An error message saying “Hmm, it's not here” appears after deleting an expense from a report that contains multiple expenses.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7108297_1774015298621.ScreenRecording_03-20-2026_09-53-06_1.1.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @JS00001 (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: #79962 - "Upgrade React Native to v0.83" by @marcochavezf (High confidence)
Related Issues: None identified

Recommendation: ROLL FORWARD

The React Native upgrade to v0.83 is a large, complex PR that touches core navigation infrastructure. Reverting this PR would be extremely disruptive as it:

• Upgrades React Native from v0.76 to v0.83
• Upgrades Expo from v52 to v55
• Includes numerous dependency updates and patches
• Has been in testing for weeks
• Required full regression testing

A targeted fix for the expense deletion navigation issue will be much safer and faster than reverting this massive upgrade.

Labels: No label changes made. Keeping DeployBlockerCash as this is a frontend bug that needs to be fixed before mobile deploy.

Detailed Analysis

Evidence

The bug occurs when:

1. User is viewing an expense in a 1:1 DM that contains multiple expenses
2. User deletes one expense
3. Expected: Navigate to another expense in the same report
4. Actual: Shows "Hmm, its not here" page (NotFoundPage)

This is a staging-only bug (not reproducible in production), and the timeframe aligns with PR #79962 being merged on 2026-03-19 into the 9.3.41-3 deploy.

Verification

PR #79962 modified navigation-related files:

• patches/react-native/react-native+0.83.1+013+fixNavigationAnimations.patch
• src/libs/Navigation/AppNavigator/createRootStackNavigator/GetStateForActionHandlers.ts

The React Native v0.83 upgrade includes changes to navigation behavior in react-navigation which could affect how the app determines the fallback route after deleting a transaction.

Root Cause

The React Native upgrade likely changed how navigation state is managed when a screen is removed from the stack. When deleting an expense, the app needs to navigate to:

1. The parent report (if only one transaction remains)
2. Another transaction in the same report (if multiple transactions exist)

The upgrade appears to have broken scenario #2, causing the app to navigate to the NotFoundPage instead of finding another transaction in the same report.

Recommended Fix

Create a targeted PR that:

1. Updates the delete transaction navigation logic to properly handle multiple transactions in a report
2. Ensures compatibility with React Native v0.83 navigation behavior
3. Tests the specific scenario: deleting an expense when multiple expenses exist in the same report

[MelvinBot]

Proposal

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

When a user opens an expense from a multi-expense report (entering the transaction thread view) and deletes it via More > Delete, a "Hmm... it's not here" page appears instead of redirecting to the remaining expense(s) in the report. This is reproducible in staging (v9.3.41-3) but not in production.

What is the root cause of that problem?

There is a race condition in MoneyRequestHeader.tsx between two Onyx updates that fire during expense deletion.

When the user deletes an expense from the transaction thread view, MoneyRequestHeader (line 611) calls setDeleteTransactionNavigateBackUrl(backToRoute) to set a guard URL in Onyx, and then immediately (line 629) calls deleteTransactions() which triggers deleteMoneyRequest() → API.write() with optimistic data that sets the parent report action to pendingAction: DELETE and the transaction thread report's reportID to null.

In ReportScreen.tsx (lines 518-520), the shouldShowNotFoundPage logic checks:

1. If deleteTransactionNavigateBackUrl is set → suppress the not-found page (return false)
2. If isDeletedTransactionThread is true → show the not-found page (return true)

Both values come from separate useOnyx subscriptions (which use useSyncExternalStore internally). If the optimistic data from API.write() reaches the component before the Onyx.set() for the guard URL propagates, there is a render frame where isDeletedTransactionThread = true but deleteTransactionNavigateBackUrl = undefined, causing the "Hmm... it's not here" page to appear.

This race condition is likely worsened in the current staging build due to the React 19.1→19.2 and React Native 0.81.4→0.83.1 upgrades, which may have changed useSyncExternalStore batching/scheduling behavior, plus the TransitionTracker V2 revert (PR #85700) which changed navigation timing fundamentals.

Notably, MoneyReportHeader.tsx (the header for the expense report view) already has a fix for this exact problem at lines 2050-2056, with a comment that explicitly acknowledges the bug:

// it's deleting transaction but not the report which leads to bug (that is actually also on staging)
// Money request should be deleted when interactions are done, to not show the not found page before navigating to goBackRoute
InteractionManager.runAfterInteractions(() => {
    deleteTransactions([transaction.transactionID], ...);
    removeTransaction(transaction.transactionID);
});

MoneyRequestHeader.tsx (the header for the individual transaction thread view) lacks this protection — it calls deleteTransactions() and removeTransaction() immediately without deferring via InteractionManager.runAfterInteractions.

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

In MoneyRequestHeader.tsx (lines 628-631), wrap the deleteTransactions and removeTransaction calls inside InteractionManager.runAfterInteractions(), matching the pattern already used in MoneyReportHeader.tsx:

Before (current code at MoneyRequestHeader.tsx:628-631):

} else {
    deleteTransactions([transaction.transactionID], duplicateTransactions, duplicateTransactionViolations, currentSearchHash, true);
    removeTransaction(transaction.transactionID);
}

After:

} else {
    InteractionManager.runAfterInteractions(() => {
        deleteTransactions([transaction.transactionID], duplicateTransactions, duplicateTransactionViolations, currentSearchHash, true);
        removeTransaction(transaction.transactionID);
    });
}

Also move the navigation calls (lines 632-637) to happen before the deferred deletion, similar to how MoneyReportHeader navigates first and then defers the delete.

What alternative solutions did you explore? (Optional)

1. Include setDeleteTransactionNavigateBackUrl in the optimistic data of deleteMoneyRequest: This would guarantee both Onyx updates are in the same batch. However, this would require modifying the shared deleteMoneyRequest function in IOU/index.ts, which has a wider blast radius.

2. Use Onyx.update() to batch both updates atomically: This would ensure the guard URL and the deletion optimistic data arrive in the same render cycle, but would require significant refactoring of how setDeleteTransactionNavigateBackUrl is called.

The recommended approach (deferring via InteractionManager.runAfterInteractions) is the simplest fix, matches the existing pattern in MoneyReportHeader, and directly addresses the timing issue.

---

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.