[Due for payment 2026-03-30] [$250] Add bank account - Next button is unresponsive after going online on Manually add BA page

[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: 9.3.21-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/folder/13176693/test-cases/41236755
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: MacBook Air 15.7.3 Chrome
App Component: Other

Action Performed:

1. Sign in to ND
2. Create a workspace
3. Open Workflows - Payments - Add bank account
4. Click "Connect manually", then Confirm
5. Enter routing and account numbers, go force offline - Next button is disabled
6. Go force online and click Next button

Expected Result:

User is navigated to the next step

Actual Result:

Next button is unresponsive, user remains on the "Manually add your bank account" page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @layacat

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022026441963143683545
• Upwork Job ID: 2026441963143683545
• Last Price Increase: 2026-02-24
• Automatic offers:
• layacat | Contributor | 110799289

[melvin-bot]

Triggered auto assignment to @johncschuster (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

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

After entering routing and account numbers on the "Manually add your bank account" page, going force offline (Next button correctly disables) and then going force online, the Next button becomes unresponsive. The user remains stuck on the page and cannot proceed.

What is the root cause of that problem?

The root cause is a combination of two issues triggered by the offline-to-online transition:

1. openReimbursementAccountPage sets isLoading: true on reconnection, which blocks form submission.

When the network changes from offline to online, ReimbursementAccountPage.tsx:293 detects this and calls fetchData(true), which calls openReimbursementAccountPage(). This READ command immediately (optimistically) sets isLoading: true on ONYXKEYS.REIMBURSEMENT_ACCOUNT (BankAccounts.ts:1027).

2. ONYXKEYS.REIMBURSEMENT_ACCOUNT and ONYXKEYS.FORMS.REIMBURSEMENT_ACCOUNT_FORM are the same Onyx key ('reimbursementAccount') (ONYXKEYS.ts:350 and ONYXKEYS.ts:900).

This means when isLoading: true is set on the reimbursement account, it also becomes formState?.isLoading in FormProvider. The submit function at FormProvider.tsx:238 checks if (!!formState?.isLoading || isLoading) { return; } and silently blocks all clicks.

Meanwhile, the page-level loading check at ReimbursementAccountPage.tsx:495 shows a ReimbursementAccountLoadingIndicator while isLoading is true. When the READ response comes back and sets isLoading: false, the form re-renders. However, the SaveResponseInOnyx middleware (SaveResponseInOnyx.ts:38) may defer the response processing if it detects the client is behind on OnyxUpdates (common after reconnection), keeping isLoading stuck at true until the update gap is resolved.

Additionally, the READ command waits for all pending WRITE commands via waitForWrites() (API/index.ts:268) before firing, which can further delay the response if there are queued writes in the sequential queue.

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

Pass shouldShowLoading: false when calling openReimbursementAccountPage from the offline-to-online reconnection handler. The form data is already loaded and visible to the user - there's no need to show a loading state just because we're refreshing data after reconnection.

In ReimbursementAccountPage.tsx, modify fetchData() to accept a parameter that controls whether the loading indicator is shown, and pass it through to openReimbursementAccountPage. Specifically:

1. Add a shouldShowLoading parameter to openReimbursementAccountPage in BankAccounts.ts (similar to how getVBBADataForOnyx already has a shouldShowLoading parameter at line 176). When false, the optimistic data should not set isLoading: true.
2. In the offline-to-online effect at ReimbursementAccountPage.tsx:293-294, call fetchData(true) in a way that propagates shouldShowLoading: false to openReimbursementAccountPage.

This keeps the form interactive while the background refresh happens, and the user can proceed with clicking Next without being blocked.

What alternative solutions did you explore? (Optional)

• Adding enabledWhenOffline to the Manual form - This would prevent the button from being disabled while offline, but doesn't address the core problem of isLoading blocking submissions after reconnection.
• Using a separate Onyx key for the form - This would decouple the form's isLoading state from the reimbursement account's loading state, but would be a larger refactor with broader implications.

---

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

[melvin-bot]

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

[melvin-bot]

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

[hungvu193]

@MelvinBot implement this