Home - Click on Add address not navigate to Wallet

[jponikarchuk]

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.3.61-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #88117
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 pro /Chrome
App Component: Workspace Settings

Action Performed:

Precondition: physical E card without address assigned.

1. Navigate to staging.new.expensify.com
2. Go to Home tab
3. Click on Add address button in Time sensitive section

Expected Result:

Tap the action, verify it navigates to Settings Wallet card page

Actual Result:

Tap the action, it navigates to Settings page of last visited rather than wallet card page unless refreshed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

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

[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: #88117 - "fix: replace HOME instead of pushing when navigating to Settings RHP" by @yuvrajangadsingh (High confidence)
Related Issues: #87655 (the issue this PR was fixing), #85122

Recommendation: REVERT

PR #88117 introduced a regression in navigation from the Home tab: clicking "Add address" navigates to the last-visited Settings page instead of the Wallet card page. The causing PR is clearly identified, is staging-only, and modifies the exact navigation file involved in the bug.

Assigned: @yuvrajangadsingh (PR author), @ShridharGoel (approving reviewer), @roryabraham (approving reviewer) from highest-confidence causing PR only
Labels: No label changes — DeployBlockerCash is correctly applied (this is a Frontend/App bug, staging-only). DeployBlocker is not present and should not be added.

Detailed Analysis

Evidence

• The deploy blocker issue (Home - Click on Add address not navigate to Wallet #88444) was auto-assigned to PR fix: replace HOME instead of pushing when navigating to Settings RHP #88117 by melvin-bot, which tracks the PR that introduced the regression.
• The issue body links directly to PR fix: replace HOME instead of pushing when navigating to Settings RHP #88117 under "Bug source: Pull Request QA execution."
• The bug is reproducible on staging (v9.3.61-0) but NOT in production, which is consistent with PR fix: replace HOME instead of pushing when navigating to Settings RHP #88117 being a staging-only change (merged April 17, 2026, included in the current StagingDeployCash Deploy Checklist: New Expensify 2026-04-21 #88394).
• The symptom — "Add address" from Home tab navigates to the last-visited Settings page instead of the Wallet card page, unless refreshed — directly matches the navigation code path changed by this PR.

Verification

• Affected file: src/libs/Navigation/helpers/linkTo/index.ts
• PR fix: replace HOME instead of pushing when navigating to Settings RHP #88117 modifies: src/libs/Navigation/helpers/linkTo/index.ts (the only file changed)
• The PR diff confirms it changes exactly the shouldChangeToMatchingFullScreen guard and the subsequent dispatch logic in linkTo.

Root Cause

PR #88117 attempted to fix a back-animation regression (#85122) by replacing the HOME fullscreen route with the target fullscreen (e.g. Settings) via StackActions.replace instead of StackActions.push. However, after dispatching the replace action for the fullscreen route, linkTo continues on line 191 and dispatches a second minimalAction unconditionally. This second dispatch runs against the navigation state before the replace has been applied, so the RHP (Right Hand Panel) route gets resolved relative to the stale fullscreen context — landing on whichever Settings screen was last visited rather than the intended Wallet card page. A page refresh re-evaluates the URL correctly, which explains why refreshing fixes the issue.

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #88117 changed StackActions.push to StackActions.replace when navigating from HOME to a Settings RHP (linkTo/index.ts:175-184). The problem is that React Navigation's StackRouter REPLACE handler re-uses preloaded routes by name match without applying the new params.

Settings is preloaded 1 second after HOME renders via usePreloadFullScreenNavigators. When StackActions.replace(SETTINGS_SPLIT_NAVIGATOR, {screen: WALLET.ROOT}) is dispatched, the default StackRouter finds the preloaded Settings route by name and re-uses it as-is — the {screen: WALLET.ROOT} params are silently dropped. The user sees whatever Settings sub-screen was preloaded (typically SETTINGS.ROOT or PROFILE.ROOT) instead of the Wallet page.

The old StackActions.push worked because the custom RootStackRouter.handlePushFullscreenAction calls getStateWithFilteredPreloadedRoutes which strips the mismatched preloaded route before the default StackRouter processes the action, forcing it to create a fresh route with the correct params. REPLACE bypasses this entirely — RootStackRouter only has a replace handler for REPORTS_SPLIT_NAVIGATOR, not for other fullscreen navigators.

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

Revert the StackActions.replace change from PR #88117 in linkTo/index.ts and restore the original StackActions.push behavior. To fix the original animation issue that PR was solving (wrong back animation direction on Android when pushing Settings on top of HOME), re-add the early return in shouldChangeToMatchingFullScreen that prevents pushing a different fullscreen when the current one is HOME — i.e., restore the guard that was removed in the same PR at line 97.

What alternative solutions did you explore? (Optional)

An alternative would be to add a generic REPLACE handler in RootStackRouter (similar to handleReplaceReportsSplitNavigatorAction) that calls getStateWithFilteredPreloadedRoutes before forwarding to the default StackRouter. This would make REPLACE work correctly with preloaded routes but adds complexity to the custom router for a problem that can be solved more simply by reverting to push.

Supporting evidence

Data flow:

1. User is on HOME. Settings preloaded after 1s with {screen: SETTINGS.ROOT}
2. User clicks "Add address" → Navigation.navigate(ROUTES.SETTINGS_WALLET_DOMAIN_CARD.getRoute(cardID))
3. linkTo processes: shouldReplace = true (last fullscreen is HOME)
4. StackActions.replace(SETTINGS_SPLIT_NAVIGATOR, {screen: WALLET.ROOT}) dispatched
5. RootStackRouter: no REPLACE handler for SETTINGS_SPLIT → falls through to default StackRouter
6. Default StackRouter REPLACE: finds preloaded Settings route by name match, reuses it as-is, {screen: WALLET.ROOT} params lost
7. Settings shows wrong sub-screen instead of Wallet

Key code locations:

• Replace logic: linkTo/index.ts:175-184
• Settings preloading: usePreloadFullScreenNavigators.ts
• RootStackRouter replace handling: RootStackRouter.ts (only handles REPORTS_SPLIT_NAVIGATOR)
• React Navigation StackRouter REPLACE: reuses state.preloadedRoutes.find(r => r.name === action.payload.name) without applying new params

Possibly related: #87655 — this is the original issue that PR #88117 was attempting to fix.

---

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.