[$250] Add BA - Currency list does not display when trying to change WS currency

[nlemma]

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.3.49-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-13513/folder/13176691/41236741/1283215421?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows Windows 10 Pro
App Component: Workspace Settings

Action Performed:

1. Create a non-USD workspace
2. Go to Workflows
3. Click on "Add bank account"
4. Click on "Update workspace currency"

Expected Result:

Currency RHP should be displayed after clicking on "Update workspace currency"

Actual Result:

No action is happening when clicking on "Update workspace currency", list is displayed after a second try.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7114082_1774537573950.ExpensifyRHPCurrencyNotDisplayed.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ChavdaSachin

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022037198654416968655
• Upwork Job ID: 2037198654416968655
• Last Price Increase: 2026-04-16

[MelvinBot]

Proposal

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

On a non-USD workspace, going to Workflows → "Add bank account" → clicking "Update workspace currency" does nothing on the first click. The currency selection RHP only appears on the second click.

What is the root cause of that problem?

This is a race condition between window.history.back() (modal cleanup) and Navigation.navigate() (deferred navigation) on web.

When the confirm modal opens, it pushes a browser history entry with {shouldGoBack: true} (Modal/index.tsx:71). When dismissed, hideModal() (Modal/index.tsx:46-63) does two things:

1. Calls onModalHide() synchronously — this resolves the confirm promise, which calls confirmCurrencyChangeAndHideModal() (WorkspaceWorkflowsPage.tsx:150-157), which schedules navigation via setNavigationActionToMicrotaskQueue (Promise.then → requestAnimationFrame)
2. Schedules setTimeout(() => window.history.back(), 0)

The execution order ends up being:

• Microtask (Promise.then) fires → schedules requestAnimationFrame
• setTimeout(0) fires → history.back() runs, popping the modal's history entry
• requestAnimationFrame fires → Navigation.navigate() runs, but history.back() already corrupted the navigation state

On the second click, shouldGoBack is no longer in the history state (consumed by the first history.back()), so hideModal takes the else branch and skips history.back() entirely — navigation succeeds.

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

In confirmCurrencyChangeAndHideModal at WorkspaceWorkflowsPage.tsx:150-157, replace Navigation.setNavigationActionToMicrotaskQueue with a direct Navigation.navigate call. This matches the pattern used in WorkspaceInvoiceVBASection.tsx:64-70 which has the same flow but navigates directly without the microtask queue deferral.

By navigating synchronously within the onModalHide callback, Navigation.navigate pushes its history entry before the setTimeout(0) fires history.back(). The setTimeout guard on line 55 checks shouldGoBack — since Navigation.navigate will have replaced the history state by that point, the guard returns early and history.back() is skipped.

What alternative solutions did you explore? (Optional)

1. Clear shouldGoBack from history state before calling onModalHide() in Modal/index.tsx — this would make the setTimeout guard always skip history.back() when the modal is closed via confirm action. However, this changes shared modal infrastructure and could have broader side effects.

2. Pass shouldHandleNavigationBack: false from the confirm modal in this specific flow — this would prevent the history entry from being pushed entirely. But this would break the hardware back button behavior while the modal is open.

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ChavdaSachin (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022037198654416968655

[trasnake87]

Proposal

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

On a non-USD workspace, clicking "Update workspace currency" in the confirm modal does nothing on the first try. The currency selection RHP only appears after a second attempt.

What is the root cause of that problem?

In confirmCurrencyChangeAndHideModal at WorkspaceWorkflowsPage.tsx#L154-L156, the navigation is wrapped in Navigation.setNavigationActionToMicrotaskQueue, which defers the actual navigate() call to a requestAnimationFrame (~16ms). Meanwhile, the confirm modal's hideModal in Modal/index.tsx#L54-L59 schedules window.history.back() via setTimeout(0) (~4ms) to clean up its guard history entry. Because requestAnimationFrame fires after setTimeout(0), history.back() runs first and corrupts the navigation state before navigate() ever executes — the navigation is silently swallowed by the stale history.

The identical flow in WorkspaceInvoiceVBASection.tsx#L69 works correctly because it calls Navigation.navigate() directly without the microtask queue wrapper.

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

Remove the unnecessary setNavigationActionToMicrotaskQueue wrapper in confirmCurrencyChangeAndHideModal so the navigation runs synchronously within the promise microtask — before the modal's setTimeout(history.back) fires. This matches the working pattern already used in WorkspaceInvoiceVBASection.tsx:

 const confirmCurrencyChangeAndHideModal = useCallback(() => {
     if (!policy) {
         return;
     }
-    Navigation.setNavigationActionToMicrotaskQueue(() => {
-        Navigation.navigate(ROUTES.WORKSPACE_OVERVIEW_CURRENCY.getRoute(policy.id, true));
-    });
+    Navigation.navigate(ROUTES.WORKSPACE_OVERVIEW_CURRENCY.getRoute(policy.id, true));
 }, [policy]);

This is safe because setNavigationActionToMicrotaskQueue exists to ensure Onyx updates flush before navigation, but confirmCurrencyChangeAndHideModal performs no Onyx updates — it only navigates. Removing the wrapper lets the navigate call push its history entry in the microtask, which the setTimeout guard at Modal/index.tsx#L55 then correctly detects (new state lacks shouldGoBack), skipping history.back() entirely.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[abbasifaizan70]

Proposal

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

When an admin in a non-USD workspace goes to Workflows and taps Add bank account, the confirmation modal for unsupported workspace currency appears. After tapping Update workspace currency, the first click can do nothing, and the user needs to try again before the currency list opens.

Expected: tapping Update workspace currency should navigate to the workspace currency page on the first try.
Actual: the first tap can no-op, and navigation only works on a second try.

What is the root cause of that problem?

The confirm handler depends on policy being available at click time and exits early when policy is temporarily undefined, which creates a race condition during modal confirmation.

App/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx

Lines 150 to 157 in 00ddfe5

	const confirmCurrencyChangeAndHideModal = useCallback(() => {
	if (!policy) {
	return;
	}
	Navigation.setNavigationActionToMicrotaskQueue(() => {
	Navigation.navigate(ROUTES.WORKSPACE_OVERVIEW_CURRENCY.getRoute(policy.id, true));
	});
	}, [policy]);

The confirmation flow itself is correctly wired to call this handler, so the no-op behavior comes from the early return in that callback rather than from modal wiring.

App/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx

Lines 456 to 466 in 00ddfe5

	showConfirmModal({
	title: translate('workspace.bankAccount.workspaceCurrencyNotSupported'),
	prompt: updateWorkspaceCurrencyPrompt,
	confirmText: translate('workspace.bankAccount.updateWorkspaceCurrency'),
	cancelText: translate('common.cancel'),
	}).then((result) => {
	if (result.action !== ModalActions.CONFIRM) {
	return;
	}
	confirmCurrencyChangeAndHideModal();
	});

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

Use a stable policyID fallback (route.params.policyID) in the confirm handler so navigation does not depend on policy hydration timing.

App/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx

Lines 150 to 157 in 00ddfe5

	const confirmCurrencyChangeAndHideModal = useCallback(() => {
	if (!policy) {
	return;
	}
	Navigation.setNavigationActionToMicrotaskQueue(() => {
	Navigation.navigate(ROUTES.WORKSPACE_OVERVIEW_CURRENCY.getRoute(policy.id, true));
	});
	}, [policy]);

const confirmCurrencyChangeAndHideModal = useCallback(() => {
    const policyID = policy?.id ?? route.params.policyID;
    if (!policyID) {
        return;
    }
    Navigation.setNavigationActionToMicrotaskQueue(() => {
        Navigation.navigate(ROUTES.WORKSPACE_OVERVIEW_CURRENCY.getRoute(policyID, true));
    });
}, [policy?.id, route.params.policyID]);

[github-actions]

⚠️ @abbasifaizan70 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.