Android & iOS - Expense- App returns to Spend after exporting & returning from Concierge

[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: 9.4.20-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: #93796
Email or phone of affected tester (no customers): sdjnoisdjdosijsonssjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Go to workspace chat.
3. Create an expense.
4. Open the report.
5. Tap More > Export > All Data - expense level.
6. Tap Send me the file when it's ready.
7. Tap Go to Concierge.
8. Tap app back button.

Expected Result:

App will return to previous page which is the expense report.

Actual Result:

App returns to Spend after exporting report and returning from Concierge.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7191477_1782428525546.Screen_Recording_20260626_065956_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7191477

[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/ec9c4890d04704bad973375c51e0a614d9128fab8a595cf34ef0dcebb3303db0

[melvin-bot]

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

[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

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

After exporting a report via the report header (More > Export > All Data) and tapping Go to Concierge, pressing the app/browser back button returns to Spend (the Search/Reports tab root) instead of the expense report the user came from.

What is the root cause of that problem?

The realtime export status modal's Go to Concierge handler hardcodes navigation into the Search/Reports stack, ignoring the navigator the user is actually in.

In ExportDownloadStatusModal.tsx:93-98, handleGoToConcierge always calls Navigation.navigate(ROUTES.SEARCH_REPORT.getRoute({reportID: conciergeReportID})). SEARCH_REPORT belongs to the Search/Reports (Spend) navigator, so Concierge is pushed onto the Search stack whose root is Spend — and it passes no backTo. When the user came from a normal expense report (the standard REPORT navigator), pressing back unwinds the Search stack to Spend rather than returning to the report.

This modal is shared with the Search bulk-export flow, where the user is already in the Search stack — so SEARCH_REPORT lines up and the bug is masked there. PR #93796 wired this same modal into the report-header export flow, which is on the REPORT navigator, exposing the mismatch.

Evidence & data flow

• Handler: ExportDownloadStatusModal.tsx:93-98 — unconditional ROUTES.SEARCH_REPORT, no backTo.
• Report-header consumer (introduced by feat: Integrate ExportDownloadStatusModal into report-level CSV export flow #93796): useExportActions.ts renders this modal from MoneyReportHeaderSecondaryActions/MoneyReportHeaderSelectionDropdown, which open from the standard REPORT navigator.
• Canonical context-aware helper that should have been used: getReportRouteForCurrentContext.ts:10-21 — picks SEARCH_REPORT only when the Search stack is topmost, otherwise REPORT_WITH_ID, and always passes backTo.

Flow: open report (REPORT stack) → export → tap Go to Concierge → navigate(SEARCH_REPORT) pushes Concierge onto the Search stack with no backTo → back unwinds Search stack to its root = Spend.

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

In handleGoToConcierge (ExportDownloadStatusModal.tsx:93-98), replace the hardcoded ROUTES.SEARCH_REPORT.getRoute(...) with the context-aware helper so the navigator and backTo match where the user actually is:

const handleGoToConcierge = () => {
    onClose();
    if (conciergeReportID) {
        Navigation.navigate(getReportRouteForCurrentContext({reportID: conciergeReportID}));
    }
};

This keeps the Search bulk-export flow working (it stays in SEARCH_REPORT when Search is topmost) while fixing the report-header flow (it uses REPORT_WITH_ID with backTo, so back returns to the expense report). Verify both flows — report-header export and Search bulk export — after the change.

Confidence: High — root cause verified against the merged code; the shared-modal asymmetry cleanly explains why it reproduces only from the report header.

---

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

[truph01]

@MelvinBot I think we should open side panel openSidePanel instead of Navigation.navigate(getReportRouteForCurrentContext({reportID: conciergeReportID}));.