Virtual Card - The background page changes to inbox after reload

[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: v9.4.27-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91634
Email or phone of affected tester (no customers): applausetester+dspr633@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 14.5/ Chrome
App Component: Other

Action Performed:

Precondition: Create an account with US Expensify Card holder with a virtual Expensify Card assigned and no/incomplete personal details on file (no legal name / DOB / phone / any address sub-field missing).

1. Navigate to https://staging.new.expensify.com/ > Login to the Account
2. go to Settings → Wallet.
3. Tap into the virtual card details page. > Click on Reveal
4. Reload on Add personal details

Expected Result:

The background page stays on Wallet page after reload

Actual Result:

The background page changes to inbox after reload

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7199244_1783157632069.Screen_Recording_2026-07-04_at_12.26.24_in_the_afternoon.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7199244

Issue Owner

Current Issue Owner: @DylanDylann

[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/0ef763b7bfc7562e7ae005aa20191f60b8bc1299031eda26b75bf7599fa18481

[melvin-bot]

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

[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: The MISSING_PERSONAL_DETAILS RHP route is not registered in any RHP→background mapping, so after a browser reload the app can't figure out what page belongs behind the modal and falls back to the default Inbox/Home.

PR #91634 changed the virtual‑card Reveal flow to navigate to ROUTES.MISSING_PERSONAL_DETAILS (ExpensifyCardPage/index.tsx:531). That route carries no backTo param (ROUTES.ts:3658) and its screen SCREENS.MISSING_PERSONAL_DETAILS is absent from every RHP→background RELATIONS file — notably the Wallet list in SETTINGS_TO_RHP.ts:34. On reload, getAdaptedStateFromPath → getMatchingFullScreenRoute finds no backTo and no RELATIONS match, returns undefined, and the background defaults to SCREENS.HOME (Inbox).

Recommended Fix: Add SCREENS.MISSING_PERSONAL_DETAILS (and its MISSING_PERSONAL_DETAILS_CONFIRM_MAGIC_CODE sibling) to the SCREENS.SETTINGS.WALLET.ROOT array in SETTINGS_TO_RHP.ts, alongside the other Wallet RHP screens (e.g. DOMAIN_CARD, REPORT_VIRTUAL_CARD_FRAUD). That routes it through the RHP_TO_SETTINGS branch and restores Wallet as the background after reload.

⚠️ Entry‑point caveat: this RHP is also opened from the Home time‑sensitive "Add personal details" card and from the physical‑card row (index.tsx:699). A static RELATIONS mapping will always restore to Wallet regardless of where it was opened. If the correct background must vary per entry point, add a backTo param to the route instead and pass it at each call site — getMatchingFullScreenRoute already honors backTo.

Investigation details

Data flow on reload:

1. Settings → Wallet → virtual card → Reveal → Navigation.navigate(ROUTES.MISSING_PERSONAL_DETAILS.getRoute(cardID)); URL becomes /missing-personal-details/<cardID> (no backTo).
2. Browser reload → app rebuilds nav state from the URL via getAdaptedStateFromPath.
3. getMatchingFullScreenRoute checks backTo (none) then each RHP_TO_* map (SEARCH / HOME / WORKSPACE / SETTINGS / SIDEBAR / …). MISSING_PERSONAL_DETAILS is in none.
4. Returns undefined → caller falls back to the default HOME background → renders Inbox instead of Wallet. ✅ matches the reported symptom.

Why prod isn't affected: the Reveal→MissingPersonalDetails navigation is new in #91634 (it replaced the old RevealCardDetails MFA scenario), so this is a regression from that PR, consistent with "Reproducible in production?: No".

Confidence: High — verified by code inspection: SCREENS.MISSING_PERSONAL_DETAILS (defined at SCREENS.ts:1002) does not appear in any file under src/libs/Navigation/linkingConfig/RELATIONS/ (the only MISSING_PERSONAL_DETAILS match there is the unrelated WORKSPACE.TRAVEL_MISSING_PERSONAL_DETAILS), and the route definition has no backTo segment.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

cc DylanDylann (PR #91634 author)

[DylanDylann]

@MelvinBot implement this