Confirm currency & country page reappears (1st step not skipped) when re-adding BA

[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.3.99-3
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - Provide reasoning.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91491
Email or phone of affected tester (no customers): kiatest.78+ck6426@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/Chrome, iPhone 16/18.7.1
App Component: Workspace Settings

Action Performed:

Precondition:

1. Logged in as new user >> Create new WS & go through adding Plaid BA in Workflows >> Payments step

2. Disconnect the added BA

3. Launch HYbrid app or Navigate to staging.new.expensify.com

4. Go to Workflows >> Payments step >> Add bank account >> Log into your bank

5. Finish the Plaid flow

6. Observe user lands on Choose currency & country step 1 instead on redirecting to Choose bank account (step 2)

Expected Result:

Choose currency & country step 1 should be skipped. User should be navigated to to Choose BA step 2 directly during re-adding BA flow

Actual Result:

Confirm currency & country page step 1 reappears during re-adding BA flow in Workflows page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7171780_1780593502496.ScreenRecording_06-04-2026_12-50-40_1.mp4

View all open jobs on GitHub

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

[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/1c3f474028d92fb2dfa768c5a63846f08531d43a7f770609d910e5c99f5637c5

[melvin-bot]

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

[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

TL;DR — Expensify/App#91491 did not cause this, and this is not a regression from the current deploy. The "Choose currency & country" step reappearing on re-add is a pre-existing bug already in production. Expensify/App#91491 was auto-assigned only because QA happened to run against its test build.

Why Expensify/App#91491 is innocent: It is the only change to ReimbursementAccountPage.tsx between production and staging, and its entire diff just gates a hideBankAccountErrors() call behind a step-transition check (to surface a duplicate-account error). It does not touch any step/navigation logic. The code that decides which step to show is byte-for-byte identical on production and staging.

Root cause: Which step you land on is decided by getInitialCurrentStep(), which falls back to the COUNTRY step whenever hasConfirmedUSDCurrency is false:

const hasConfirmedUSDCurrency = (reimbursementAccountDraft?.[INPUT_IDS.ADDITIONAL_DATA.COUNTRY] ?? '') !== '' || (achData?.accountNumber ?? '') !== '';

On the re-add flow (add Plaid BA → disconnect → re-add), the draft has been cleared and achData.accountNumber is empty (the account was just disconnected), so hasConfirmedUSDCurrency evaluates to false → getInitialCurrentStep() returns STEP.COUNTRY → the user lands on "Choose currency & country" (step 1) instead of "Choose bank account" (step 2). getStepToOpenFromRouteParams has the same false-branch behavior for the NEW route.

Recommended next steps

1. Don't block the deploy on Expensify/App#91491 — it didn't introduce this. Re-triage / reassign.
2. Validate in production (the report says prod was "unable to validate"). Since the navigation code is identical on prod ↔ staging, it should reproduce in production — which confirms it's pre-existing, not a deploy blocker.
3. The real fix is in the USD VBBA flow: hasConfirmedUSDCurrency / getInitialCurrentStep need to treat a re-add on an already-USD workspace as "currency already confirmed" so the FE-only COUNTRY step is skipped. This flow has been reverted/reapplied/refactored several times, so its owners should confirm the intended re-add behavior before changing the heuristic.

Investigation details & evidence

• prod ↔ staging diff: gh api repos/Expensify/App/compare/production...staging shows Expensify/App#91491 as the only change to ReimbursementAccountPage.tsx, and its diff only adds usePrevious/isFirstRenderRef gating around hideBankAccountErrors() — no routing changes.
• Byte-identical nav code: hasConfirmedUSDCurrency (L130) and getInitialCurrentStep (L138-144) are identical on production (ce9b3f3) and staging (032144f).
• Util untouched in this deploy: getStepToOpenFromRouteParams.ts last changed 2025-08-11; not in this release.
• Suspected origin (medium confidence): the current hasConfirmedUSDCurrency heuristic was (re)introduced by the USD-flow restore/refactor work (feat: 79048 restore reverted usd flow #88193, later feat: Refator USD flow to use useSubPage #90302), both already in production well before this deploy. GitHub's GraphQL blame endpoint was returning 502s, so this attribution relies on file-level commit history + byte-equality checks against historical refs rather than a clean line blame.
• Confidence: root-cause mechanism — high; Expensify/App#91491 not being the cause — high; exact one-line fix — medium (depends on intended re-add behavior in this sensitive flow).

---

Next Steps: Reply with @MelvinBot implement this to create a draft PR for the hasConfirmedUSDCurrency fix, or @MelvinBot <your feedback> to refine this analysis.

[youssef-lr]

CP https://expensify.slack.com/archives/C07J32337/p1780605937377909

[IuliiaHerets]

Chrome / v9.3.99-7
Not repro on Web

REC-20260605105406.mp4