Pay with BA-User is navigated to the Inbox instead of report after exiting "Add BA" modal

[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.34-5
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: #93087
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 iOS 26.5.2
App Component: Money Requests

Action Performed:

1. Sign up to ND with a new gmail account with a +
2. Select “Something else” purpose
3. Tap “+” button, select “Create a workspace”
4. Navigate to the Inbox tab - tap FAB - create an expense
5. Tap Submit on the expense preview, then Approve
6. Navigate to the Spend tab > Expenses
7. Click on the Expense
8. Click on the Pay Button > Pay with business account
9. Enter the magic code
10. Tap Back button on the “Add bank account” modal

Expected Result:

User is navigated back to the expense report in the Spend tab

Actual Result:

After validating the account and exiting “Add Bank account” modal, user is navigated to the Inbox

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208568_1784069417201.BA_iOS_2_navigating_wrong.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @jmusial

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

[melvin-bot]

@mountiny recently merged #93087, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

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

Proposal

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

An unvalidated user who opens an expense report from the Spend tab, taps Pay → Pay with business account, validates via the magic-code screen, then taps Back on the resulting Add bank account modal is dropped on the Inbox instead of returning to the expense report. This is a regression from #93087 (merged in 6ce0d0c), which is in this deploy.

What is the root cause of that problem?

Before #93087, an unvalidated payer's action was simply aborted and they were sent to verify-account — nothing resumed, so the navigation stack was never disturbed. #93087 changed this so the payment resumes automatically after validation via the new useVerifyAccountAndResume hook, which navigates to the verify-account dynamic route (useVerifyAccountAndResume.ts:59).

The problem is that navigating to a dynamic route replaces the entire Right-Modal (RHP) stack with a single route rather than stacking on top of it:

const rootRoute = {routes: [buildNestedState(routeConfig, 0)]};

getStateForDynamicRoute.ts:112

A Spend-tab expense report (SEARCH_MONEY_REQUEST_REPORT) is itself an RHP screen over the Search central pane. When the dynamic route is built, that report screen is used only to derive params — it is not kept in the resulting RHP routes array. So once verify-account opens, the report no longer exists in the stack. After validation the resumed onPress opens Add bank account (REIMBURSEMENT_ACCOUNT) in that same modal, and dismissing it pops the RHP back to the central pane (Inbox) because there is no report screen left beneath it.

Evidence chain (high confidence — verified against merge commit 6ce0d0c)

1. Unvalidated pay → SettlementButton/index.tsx:254 calls verifyAccountAndResume(retry), where retry is the payment onPress (which opens the KYC/Add-BA flow).
2. The hook navigates to search/r/{reportID}/verify-account (useVerifyAccountAndResume.ts:59); verify-account lives in the RIGHT_MODAL.SETTINGS modal — a sibling of the report's RHP screen, not a child.
3. getStateForDynamicRoute rebuilds the RHP state as a single nested route (line 112), discarding SEARCH_MONEY_REQUEST_REPORT.
4. On success the hook resumes the payment (useVerifyAccountAndResume.ts:45-50) → Add-BA modal opens in the same SETTINGS modal. Its backTo is computed at render as Navigation.getActiveRoute() (SettlementButton/index.tsx:659), which by resume time no longer resolves to the report.
5. Back on Add-BA pops the RHP → central pane / Inbox.

The useShouldRenderOverlay.ts change in the same PR is an unrelated overlay-flicker guard and is not the cause.

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

Because this is a DeployBlocker, the lowest-risk options are:

• Fastest / safest: capture the report route at press time (before the verify-account navigation) inside the pendingAction payload, and thread it as the backTo for the resumed Add-bank-account route instead of the render-time Navigation.getActiveRoute() at SettlementButton/index.tsx:659. This makes Back target the report explicitly.
• If a clean fix can't land in time: revert #93087 to unblock the deploy, then re-land with the fix.

What alternative solutions did you explore?

A more durable (but higher-risk) fix: when the base/focused route is itself an RHP screen, have getStateForDynamicRoute build the RightModalNavigator routes as [<baseReportRoute>, <verify-account>] with index: 1 so the report survives underneath the dynamic route. This fixes the dynamic-route-from-RHP pattern generally, but it touches shared navigation logic and should not be rushed into a deploy-blocker fix.

Open question

The same mechanism should also affect reports opened from the Inbox tab (EXPENSE_REPORT / SEARCH_REPORT are also RHP screens), so the regression likely isn't Spend-tab-specific. Worth confirming during the fix.

---

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