[Due for payment 2026-03-19] Bank Account - Delete modal not display and Wallet page blank when trying to delete any account

[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.36-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-8437/folder/13176692/41236751/1244460498?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 10
App Component: User Settings

Action Performed:

Precondition: Has a new expensifail account with two non-US deposit accounts and one US deposit account added in Wallet .

1. Navigate to the Wallet page

2. Click the 3-dot menu for one of the non-US deposit account that doesn’t have the default badge

3. Click Make default payment method
   4.Click the 3-dot menu on new default account

4. Click Delete and confirm deleted modal
   Result: Wallet page renders blank instead of showing modal

5. Refresh page

6. Verify the bank account is removed from the list
   Result: Any account can be removed

7. Try to deled a non default account > Wallet page renders blank instead of showing modal and any account can be removed

8. Check behavior in offline > Wallet page renders blank instead of showing modal and any account can be removed

Expected Result:

After clicking "Delete" the confirmation modal should appear and the selected bank account should be successfully removed from the Wallet list.

Actual Result:

After clicking "Delete", the Wallet page becomes blank. The user must manually refresh the page, and after refreshing the bank account is still visible in the list and is not removed. Same behavoir note for offline.

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]

Triggered auto assignment to @yuwenmemon (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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #84860 - "Bump Onyx to 3.0.45" by @pasyukevich (High confidence)
Related Issues: #80094

Recommendation: REVERT

The Onyx version bump from 3.0.43 to 3.0.45 (PR #84860) is the most likely cause of this regression. The timing aligns perfectly:

• Issue is reproducible on staging (v9.3.36-0) which includes this Onyx bump
• Issue is NOT reproducible on production, which has the previous Onyx version
• The blank screen when deleting bank accounts suggests a state management issue, which is exactly what Onyx handles

Labels: Keeping DeployBlockerCash - this is a frontend bug that blocks the App deploy. The fix needs to happen in the App repo (either reverting the Onyx bump or waiting for a fixed Onyx version).

Detailed Analysis

Evidence

The bug manifests when users attempt to delete a bank account from the Wallet page:

1. User clicks "Delete" on a bank account
2. Expected: Confirmation modal appears
3. Actual: Wallet page renders blank instead

After page refresh, the bank account is still present (deletion did not occur).

Root Cause Analysis

The deletion flow in /src/pages/settings/Wallet/WalletPage/index.tsx uses the showConfirmModal hook to display a confirmation dialog. When the modal is triggered, the page state appears to be getting cleared or corrupted, resulting in a blank screen.

The Onyx library (react-native-onyx) handles all state persistence and management in the app. A bug in Onyx 3.0.45 could cause:

• State to be incorrectly cleared when modals are displayed
• React component re-render issues when Onyx data updates
• Race conditions in state updates

Verification

• PR Bump Onyx to 3.0.45 #84860 was merged on March 11, 2026 at 16:27:05Z
• It bumped Onyx from 3.0.43 to 3.0.45
• This PR is included in the v9.3.36-0 staging deploy where the bug reproduces
• The bug does NOT reproduce on production (which has an earlier version)
• No other PRs in the staging deploy directly touch the Wallet page deletion flow

Alternative Candidates Considered

I also investigated:

• PR Fix deleteWorkspace optimistic update to handle policyIDs bank account association #84828 (deleteWorkspace bank account handling) - Not related to personal bank account deletion
• Changes to modal/confirm components - No changes found in staging deploy
• Changes to WalletPage itself - No direct changes in this deploy

[MelvinBot]

Proposal

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

When a user tries to delete a bank account from the Wallet page via the 3-dot menu, the entire Wallet page goes blank instead of showing a confirmation modal. After refreshing, the bank account is still present (the deletion never occurs). This is a regression in staging v9.3.36-0 that does not reproduce in production v9.3.35-1.

What is the root cause of that problem?

PR #82510 ("Fix: Screen Reader: Many Pages: There is no dialog role and title announced", merged 2026-03-11, commit fc1712ae) introduced a crash in the Header component that occurs when it renders outside NavigationContainer.

The crash path:

1. User clicks "Delete" in the 3-dot menu on a bank account
2. The onSelected handler calls closeModal(() => showDeleteAccountModal()) (WalletPage/index.tsx:479)
3. showDeleteAccountModal calls showConfirmModal() from the useConfirmModal hook, which calls context.showModal() on the global ModalProvider
4. ModalProvider renders ConfirmModalWrapper as a sibling of {children} (ModalContext.tsx:97-106) — this means it renders outside NavigationContainer
5. ConfirmModalWrapper -> ConfirmModal -> ConfirmContent -> Header (ConfirmContent.tsx:190)
6. Header (modified by PR fix: Screen Reader: Many Pages: There is no dialog role and title announced #82510) now calls useDialogTitleFocus(titleRef, isInsideDialog) unconditionally
7. The web implementation of useDialogTitleFocus calls useNavigation() at the top of the function body, before any guard on isInsideDialog
8. useNavigation() throws "Couldn't find a navigation object" because the component is not inside NavigationContainer
9. The uncaught error crashes the React tree, and the ErrorBoundary replaces the entire app with an error page (perceived as "blank")

Why staging-only: PR #82510 is in staging v9.3.36-0 (fc1712ae is 178 commits behind the staging tag) but NOT in production v9.3.35-1 (diverged, 600 commits behind).

Why web-only: The native useDialogTitleFocus/index.native.ts is a no-op, so this crash only affects web/mWeb (matching the report: "Windows: Chrome").

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

The fix should be in src/hooks/useDialogTitleFocus/index.ts. The useNavigation() call needs to be guarded so it doesn't throw when the component is rendered outside NavigationContainer. Two options:

1. Wrap useNavigation() in a try/catch to gracefully handle the missing navigation context and return early when outside NavigationContainer.
2. Use useNavigationState with a selector or a custom hook that checks for navigation context availability before accessing it (e.g., check if NavigationContext has a value).

Since React hooks can't be called conditionally, the guard must be inside the hook itself, not at the call site in Header.tsx.

What alternative solutions did you explore? (Optional)

• Reverting PR fix: Screen Reader: Many Pages: There is no dialog role and title announced #82510: This would fix the issue but would lose the screen reader accessibility improvements. A targeted fix is preferable.
• Moving ModalProvider's rendering inside NavigationContainer: This would be a larger architectural change with broader implications and is not recommended as a quick fix.
• Onyx 3.0.45 revert (PR Bump Onyx to 3.0.45 #84860): This was investigated as an alternative cause but the evidence points to the useNavigation() crash as the primary issue. The Onyx bump changes the caching layer for useOnyx but would not directly cause a crash during modal rendering.

Detailed Investigation

Evidence Chain

Evidence	Location
PR #82510 adds useDialogTitleFocus to Header.tsx unconditionally	PR diff - Header.tsx
useDialogTitleFocus web impl calls useNavigation() at top of function	PR diff - useDialogTitleFocus/index.ts:2,17
ConfirmContent renders Header	src/components/ConfirmContent.tsx:190-193
ModalProvider renders ConfirmModalWrapper outside NavigationContainer	src/components/Modal/Global/ModalContext.tsx:97-106
PR #82510 merged 2026-03-11, in staging but not production	Merge commit fc1712ae, confirmed via tag comparison
Native useDialogTitleFocus is a no-op	PR diff - useDialogTitleFocus/index.native.ts

Scope of Impact

This crash affects all uses of showConfirmModal from the useConfirmModal hook on web, not just the Wallet delete flow. Other affected flows include any page that was migrated from inline ConfirmModal to useConfirmModal in PR #79553 (e.g., ContactMethodDetailsPage delete, VacationDelegatePage warning, VisibilityPage public visibility).

Contributing Factor

PR #79553 (merged 2026-02-23, in both staging and production) migrated the WalletPage delete confirmation from an inline <ConfirmModal> (rendered inside the page, inside NavigationContainer) to showConfirmModal() via useConfirmModal (rendered by global ModalProvider, outside NavigationContainer). This created the architectural vulnerability that PR #82510 exploits.

---

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.