[Due for payment 2026-06-30] [Due for payment 2026-06-29] Expensify Card - After reporting card lost, back button opens not here 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: 9.4.16-1
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: https://github.com/Expensify/Mobile-Expensify/pull/13968
Email or phone of affected tester (no customers): applausetester+khffsohsojsojosjo@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account (each Expensifail account has a physical card).

1. Launch Expensify app.
2. Go to Account > Wallet.
3. Click on the physical card.
4. Click Get physical card.
5. Enter all the details and enter magic code on confirm page.
6. Tap app back button.
7. Go to Account > Troubleshoot.
8. Click Switch to Expensify Classic.
9. Open menu > Settings > Connected Cards.
10. Click Manage card.
11. Tap Report card lost or damaged.
12. Select any reason > Next.
13. Tap Ship new card.
14. Enter magic code.
15. Tap Got it.
16. Tap app back button.

Expected Result:

App will return to OD.

Actual Result:

Not here page opens.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7185821_1781899725917.ScreenRecording_06-20-2026_04-01-25_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7185821

[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/227e46f67ecec2b96cdbefe30c1e2d048454c0938e94a9d84cf1faeedc6b8577

[melvin-bot]

Triggered auto assignment to @yuwenmemon (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]

Issue Analysis

Root Cause (medium confidence): This is a HybridApp (OldDot → NewDot → OldDot) navigation bug. The "report card lost" flow is launched from Expensify Classic as a single NewDot RHP route. The final "Got it" button does Navigation.navigate(SETTINGS_WALLET_DOMAIN_CARD, {forceReplace: true}), which replaces that single route instead of pushing — so the RHP stack collapses to exactly one entry. When the native back button is then pressed, there is no NewDot route left to dismiss back to, and route resolution falls through to the catch-all SCREENS.NOT_FOUND ('*') — the "Not here" page — instead of handing control back to OldDot.

The clean "back → return to OldDot" handoff lives in the native Mobile-Expensify layer, and the regression was caught by Mobile-Expensify PR #13968 — so the fix most likely belongs there, not in App.

⚠️ This fix requires changes outside the Expensify/App repo (Mobile-Expensify / native HybridApp back handling), which I can't access. The DeployBlockerCash owner should escalate to an internal engineer with Mobile-Expensify access. Given it's a deploy blocker, the fastest path is to evaluate reverting Mobile-Expensify PR #13968.

Why this (and not the card page itself): The reporter sees the card page fine at step 14 ("Got it"), and "Not here" only appears at step 15 (back button). That rules out the in-page !currentCard NotFoundPage fallback in ExpensifyCardPage (which would fire immediately at step 14) and points squarely at the back-navigation handoff.

Investigation details & evidence

Flow (all NewDot RHP, nested under RIGHT_MODAL.SETTINGS):

1. OldDot (Connected Cards → Manage card → Report card lost or damaged) deep-links into NewDot, launching the lost-card flow as a single RHP route — no NewDot full-screen history beneath it.
2. Reason → Next → Ship new card → magic code page (ReportCardLostConfirmMagicCodePage.tsx).
3. On success, SuccessReportCardLost ("Got it") renders inside the same RHP route.
4. "Got it" → forceReplace → linkTo sets action.type = REPLACE. RHP SETTINGS stack now holds one route (DOMAIN_CARD).
5. Native back → RHP dismiss path. closeRHPFlow sees hasMoreThanOneRoute === false and pops the whole modal navigator. With no valid underlying NewDot route (single-route HybridApp launch), resolution falls to NOT_FOUND → "Not here".

Secondary path considered & ruled out by the symptom timeline: ExpensifyCardPage renders NotFoundPage when !currentCard, and it only searches useNonPersonalCardList() (personal/CSV cards filtered out). This would render the identical "Not here" UI — but it would do so at step 14, not step 15, so it isn't the reported failure.

To confirm definitively (log-investigator / runtime): dump the NewDot navigation state immediately before/after the "Got it" forceReplace and after the native back press, and confirm the resolved route name is SCREENS.NOT_FOUND vs Settings_Wallet_DomainCard. FullPageNotFoundView emits a StatsCounter('FullPageNotFoundView') that can corroborate frequency on v9.4.16-1 iOS.

---

Next Steps: This needs a Mobile-Expensify engineer. Reply with @MelvinBot <your feedback> to refine this analysis.

[heekinho]

This is being addressed here: #93910