[$250] RHP closes unexpectedly when navigating between expense reports using prev/next arrows

[Julesssss]

Connection/timing

Discovered during review of #86238 but reproduces on staging independently of those changes.

Description

When viewing an expense report opened from search results, rapidly clicking the prev/next navigation arrows causes the RHP to dismiss unexpectedly. The panel closes as if the report was deleted, even though the user is simply navigating to the next report in the list.

Steps to reproduce

1. Run a search filtered to Expense Reports with several results
2. Open one of the expense reports (RHP opens)
3. Rapidly click the next (or prev) arrow multiple times

Expected behavior

The RHP stays open and displays each successive report.

Actual behavior

The RHP closes mid-navigation, returning the user to the search results list.

Root cause (high level)

SearchMoneyRequestReportPage has a removal-detection effect that dismisses the modal when the report becomes undefined while the previous report was a money request report. During arrow navigation, the route params update before Onyx resolves the new report data, creating a brief window where the report is undefined — which the effect misinterprets as a deletion.

Platform

Reproduces on web (staging). Likely affects all platforms.

Issue Owner

Current Issue Owner: @aimane-chnaif

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043758139918298894
• Upwork Job ID: 2043758139918298894
• Last Price Increase: 2026-04-13

[leshniak]

@Julesssss thanks for creating a ticket. I'm already working on this, there is an internal discussion around the proposal.

[MelvinBot]

Proposal

What is the root cause of that problem?

SearchMoneyRequestReportPage has a removal-detection effect (SearchMoneyRequestReportPage.tsx:94-110) that calls Navigation.dismissModal() when report becomes undefined while prevReport was a money request report.

During prev/next arrow navigation, MoneyRequestReportNavigation.tsx:63-70 calls Navigation.setParams({reportID: newId}), which synchronously updates the route params. This causes useOnyx to subscribe to a new Onyx key (report_newID). If the new report data isn't in Onyx's cache yet, report is briefly undefined — and the effect misinterprets this transient loading state as a deletion, dismissing the RHP.

The existing firstRenderRef guard only protects the initial mount and is never reset on subsequent navigations.

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

Track the previous reportIDFromRoute and skip the dismissal when the route ID just changed (i.e., navigation is in progress, not a deletion):

In the removal-detection effect, add a check: if prevReportIDFromRoute !== reportIDFromRoute, return early — the undefined report is due to a route change, not a report removal.

There is already a precedent for this pattern in the same file at line 211 where prevReportIDFromRoute is compared to reportIDFromRoute for isInitialMountRef.

What alternative solutions did you explore? (Optional)

Resetting firstRenderRef.current = true when reportIDFromRoute changes was considered but is less explicit — it overloads the "first render" concept to also mean "first render after navigation." Comparing route IDs directly makes the intent clearer.

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @suneox (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022043758139918298894

[trasnake87]

Proposal

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

Rapidly clicking the prev/next arrows on an expense report opened from search closes the RHP, because the screen briefly sees the new report as undefined during route-param swaps and treats it as a deletion.

What is the root cause of that problem?

MoneyRequestReportNavigation.goToReportId (MoneyRequestReportNavigation.tsx:63-70) calls Navigation.setParams immediately without ensuring the destination report exists in the Onyx cache. PrevNextButtons only disables its buttons based on index boundaries (hideNextButton/hidePrevButton at lines 24-25) — there is no gating on whether the next report's data has arrived, so clicks fire back-to-back faster than Onyx can hydrate the new report_<id> key, producing the transient undefined window.

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

Subscribe to the target report(s) and block the arrow handlers until the next/prev report is hydrated in Onyx, so route params never swap to an unknown key:

const nextReportID = allReports.at((currentIndex + 1) % Math.max(allReports.length, 1));
const prevReportID = allReports.at((currentIndex - 1 + allReports.length) % Math.max(allReports.length, 1));
const [nextReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${nextReportID}`, {canBeMissing: true});
const [prevReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${prevReportID}`, {canBeMissing: true});

const goToNextReport = () => {
    if (!nextReport) return; // wait for Onyx hydration, swallows rapid clicks
    goToReportId(nextReportID);
};

Combined with passing isNextButtonDisabled={hideNextButton || !nextReport} to PrevNextButtons, rapid clicks are absorbed until hydration completes, eliminating the undefined window entirely without touching SearchMoneyRequestReportPage.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!