[$250] App crash when setting up a company bank account

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.15-3
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Go to New Expensify.
2. Navigate to account settings.
3. Go to Wallet / bank account setup.
4. Start adding a new company bank account.
5. Follow the setup flow.

Expected Result:

The admin should be able to complete the company bank account setup successfully in New Expensify.

Actual Result:

The setup flow fails and New Expensify displays the error: “Uh-oh, something went wrong!” The issue persists even after completing all local troubleshooting steps.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022069409446289157484
• Upwork Job ID: 2069409446289157484
• Last Price Increase: 2026-07-14

[MelvinBot]

Issue Analysis

Root Cause (Medium confidence): "Uh-oh, something went wrong!" is the app-wide ErrorBoundary/GenericErrorPage screen — so this is an unhandled render exception in the company bank account (VBBA) flow, not an inline form error. The most likely trigger is that the Settings → Wallet → "Add bank account" → "Make payments" (business) path enters ReimbursementAccountPage with no policyID and no bankAccountID, which bypasses both the loading guard and the not-found guard (both are gated on policyID). The flow then renders step components purely off whatever reimbursementAccount.achData / draft state happens to be in Onyx — including stale/partial state from a previously abandoned setup — with no local try/catch, so any malformed/unexpected state throws straight to the crash boundary.

⚠️ I could not pin down the exact throwing line from static code alone — the static guards skip cleanly, so the crash is a runtime data condition. A Sentry stack trace for 9.4.15-3 scoped to these components would confirm it instantly. This is consistent with QA being unable to reproduce (it depends on the user's specific Onyx state / a partially-completed prior setup).

Recommended next step: Pull the Sentry crash for 9.4.15-3 filtered to ReimbursementAccountPage / VerifiedBankAccountFlowEntryPoint / USDVerifiedBankAccountFlowPage / useSubPage to get the exact undefined-property access, then guard that render path.

Investigation details & evidence

Symptom is the generic crash boundary (confirmed)

• src/languages/en.ts:8679 — genericErrorPage.title: 'Uh-oh, something went wrong!', rendered by GenericErrorPage.tsx:47. This is the ErrorBoundary fallback → an uncaught render exception, not a bank-form validation error.

Entry path carries no policyID (verified)

• WalletPage/index.tsx:258-264 — admins go to ROUTES.SETTINGS_BANK_ACCOUNT_PURPOSE; the "Make payments" branch confirms a country and calls navigateToBankAccountRoute({backTo}).
• navigation.ts:23-24 — policyID defaults to '', bankAccountID undefined → route resolves to bank-account/new with no params.
• ReimbursementAccountPage.tsx:465-485 — the ReimbursementAccountLoadingIndicator guard and the FullPageNotFoundView (not-authorized) guard are both gated on policyIDParam/bankAccountIDParam. In the Wallet entry these are skipped, and fetchData early-returns (no openReimbursementAccountPage call), so the page renders directly off existing Onyx/draft state.

Prime regression surface — the useSubPage URL-step refactor

• The USD company step (BusinessInfo) and the NonUSD flow were rebuilt on src/hooks/useSubPage/index.tsx, which contains a literal render-time throw new Error('All pages are skipped') (line 44) and redirects via navigation.setParams in an effect. Step components are selected from achData + URL params with no local error handling — a confirmed crash mechanism in the hook the whole flow depends on.

Alternatives considered

• Backend/Auth failure: a failed BankAccount_SetupWithdrawal/openReimbursementAccountPage API would normally surface an inline error, not crash the whole app. The full-page ErrorBoundary screen points to a client render throw, so the fix is in App — but a Sentry trace is needed to rule out an asset/lazy-load failure as the trigger.
• Stale Onyx race: CountrySelection calls clearReimbursementAccount() (async Onyx) immediately before navigate(), so the page can briefly render against stale achData (e.g. state: OPEN/currentStep: ENABLE from a prior workspace setup) → ConnectedVerifiedBankAccount with mismatched/empty policy data. Plausible and worth checking against the stack trace.

Why QA can't reproduce: the crash depends on the user's leftover Onyx state from a prior partial setup and/or a specific beta/flag, not a clean deterministic path — so a fresh test account won't hit it.

Possibly related

• Expensify/App#90572 — "[CFI] Add Plaid connect/reconnect flow to NewDot" (touches the same bank-account connect flow; low-confidence overlap).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94310) to create a draft PR (recommend confirming the exact crash via Sentry first, since the throwing line isn't yet pinned down).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[dostonbunyodov0006]

Proposal

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

Starting the company (verified) bank account setup flow in New Expensify (Settings → Wallet → add company bank account) deterministically renders the full-screen crash page "Uh-oh, something went wrong!" instead of the setup form. It reproduces on every platform (Android, iOS, Windows/macOS Chrome & Safari, mWeb) and persists across local troubleshooting, so this is a render-time exception bubbling to the app ErrorBoundary, not a one-off API failure.

What is the root cause of that problem?

The flow renders a step component before the data that step depends on has finished loading, and a field access inside that step throws on the half-loaded store.

ReimbursementAccountPage picks the step synchronously:

const getInitialCurrentStep = () => {
    if (!hasConfirmedUSDCurrency) {
        return CONST.BANK_ACCOUNT.STEP.COUNTRY;
    }
    return achData?.currentStep ?? CONST.BANK_ACCOUNT.STEP.COUNTRY;
};
const currentStep = getInitialCurrentStep();

and then hands the flow to VerifiedBankAccountFlowEntryPoint, which mounts a step component immediately. For a brand-new company account, achData and the Corpay-backed field metadata (corpayFields / corpay onboarding fields) arrive on separate Onyx writes. The page's single hasLoadedData guard only proves reimbursementAccount.achData exists — it does not prove the corpay field list a step iterates over is present. So a step renders against a partially-hydrated store and does something like corpayFields.formFields.map(...) / reads a nested field on undefined → TypeError → bubbles to ErrorBoundary → generic crash screen.

The deeper issue: readiness is asserted field-by-field inside each step (and one slice is missed), instead of once at the flow boundary. Any step that forgets a guard, or any new step, reintroduces the same crash.

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

Gate the entire flow on a single readiness predicate so no step ever renders against a half-loaded store. Make "partially-loaded" unrepresentable at the boundary instead of defending it in every step.

-    // hasLoadedData only proves achData exists, not the step's other deps
-    const hasLoadedData = !isEmptyObject(reimbursementAccount?.achData);
+    // The flow is ready only when EVERY slice a step can read is hydrated.
+    const isFlowDataReady =
+        !isEmptyObject(reimbursementAccount?.achData) &&
+        !reimbursementAccount?.isLoading &&
+        !isLoadingCorpayFields &&            // corpay field metadata settled (loaded or confirmed absent)
+        !isEmptyObject(policy);              // admin policy hydrated

-    return (
-        <VerifiedBankAccountFlowEntryPoint
-            reimbursementAccount={reimbursementAccount}
-            ...
-        />
-    );
+    if (!isFlowDataReady) {
+        return <FullPageOfflineBlockingView><ReimbursementAccountLoadingIndicator /></FullPageOfflineBlockingView>;
+    }
+    return (
+        <VerifiedBankAccountFlowEntryPoint
+            reimbursementAccount={reimbursementAccount}
+            ...
+        />
+    );

So the step components are only ever mounted once their data exists — the corpayFields.formFields.map(...)-style access can no longer run on undefined. The readiness check lives in one place (the flow boundary), so adding a future step can't reintroduce this crash class.

To keep this from silently regressing, the same predicate should also trigger fetching any missing slice on mount (kick the corpay-fields fetch if it hasn't run) and the existing offline indicator should drive the blocking view, so the user sees a spinner — never the generic crash page — while data settles.

What alternative solutions did you explore?

• Add an optional-chain / null guard inside the throwing step (e.g. corpayFields?.formFields?.map). Fixes only the one step that happens to throw today; every other step and every future step can crash the same way. Whack-a-mole, not a root-cause fix.
• Wrap the bank-account flow in a step-scoped ErrorBoundary so a throw shows an inline recoverable error instead of the full-screen crash. Improves resilience but hides the real bug (the user still can't complete setup) and masks the missing data dependency.
• Block setup until the backend marks the account ready (poll achData.state). Couples the client to backend state machine timing, still races the separate corpay write, and adds latency for the common already-loaded case.

[melvin-bot]

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

[kitvasyl]

Proposal

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

When an admin starts setting up a company bank account on web, New Expensify can hit the app error boundary and show “Uh-oh, something went wrong!” instead of letting the admin continue the bank account setup flow.

What is the root cause of that problem?

The crash is in src/pages/ReimbursementAccount/VerifiedBankAccountFlowEntryPoint.tsx when building personalBankAccounts:

Object.keys(bankAccountList).filter((key) => bankAccountList[key].accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT)

BANK_ACCOUNT_LIST is an Onyx collection and it can contain null members. For example, deletePaymentBankAccount() in src/libs/actions/BankAccounts.ts intentionally merges {[bankAccountID]: null} into BANK_ACCOUNT_LIST on success so deleted accounts stay cleared. If any such null entry exists, opening the company bank account setup entry point dereferences bankAccountList[key].accountType, throws, and the page falls into the generic “Uh-oh” error boundary.

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

Update VerifiedBankAccountFlowEntryPoint to tolerate null collection members when checking for existing personal bank accounts, for example:

const personalBankAccounts = bankAccountList
    ? Object.values(bankAccountList).filter((bankAccount) => bankAccount?.accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT)
    : [];

Or keep the current key-based structure and use bankAccountList[key]?.accountType. This is the smallest local fix because the component only needs to know whether any personal bank account exists for the informational note; null deleted entries should simply be ignored.

Manual verification: add or simulate a null entry in BANK_ACCOUNT_LIST, open the company bank account setup flow, and verify the entry screen renders instead of showing the error boundary. Also verify that an actual personal bank account still shows the existing connectBankAccountNote message.

What alternative solutions did you explore? (Optional)

We could try to prevent null entries from ever being stored in BANK_ACCOUNT_LIST, but that would change the existing deletion/offline cleanup behavior in BankAccounts.ts. The safer fix is to make this read site handle the nullable collection shape it already receives.

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

The screenshot is the app-wide ErrorBoundary fallback — the entire app is replaced by the full-page "Uh-oh, something went wrong!" screen, with only Refresh / Sign out to recover. That tells us two separate things: (1) an uncaught exception is thrown while rendering somewhere in the company bank-account (VBBA) flow, and (2) the flow has no error containment of its own, so that throw propagates all the way up to the single root boundary registered in App.tsx:

App/src/App.tsx

Line 130 in be8591c

<ErrorBoundary errorMessage="NewExpensify crash caught by error boundary">

ReimbursementAccountPage renders the whole multi-step flow (entry point + ~15 USD/NonUSD step components) directly, with no boundary around it:

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 542 to 555 in be8591c

	return (
	<VerifiedBankAccountFlowEntryPoint
	setShouldShowContinueSetupButton={setShouldShowContinueSetupButton}
	reimbursementAccount={reimbursementAccount}
	onContinuePress={isNonUSDSetup ? continueNonUSDVBBASetup : continueUSDVBBASetup}
	policyName={policyName}
	backTo={backTo}
	shouldShowContinueSetupButton={shouldShowContinueSetupButton}
	isNonUSDWorkspace={isNonUSDSetup}
	setUSDBankAccountStep={setUSDBankAccountStep}
	policyID={policyIDParam}
	isComingFromExpensifyCard={isComingFromExpensifyCard}
	/>
	);

Because every step renders off whatever reimbursementAccount.achData / bankAccountList / draft state happens to be in Onyx for that specific user, a single malformed or partially-hydrated entry anywhere in the flow throws during render and takes down the whole app, not just the RHP. This is also why it can't be reproduced on a clean test account — it depends on the reporter's own Onyx state — matching the "Unable to reproduce" note.

The other proposals on this issue each correctly guard one specific field that can throw today (e.g. bankAccountList[key]?.accountType at VerifiedBankAccountFlowEntryPoint.tsx#L104). That is necessary, but it is whack-a-mole: any other malformed Onyx slice read by any of the remaining step components — or any step added later — reproduces the exact same full-app crash. This proposal addresses the orthogonal problem the screenshot reveals: the flow's blast radius is the entire app.

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

Wrap the bank-account flow subtree in a scoped ErrorBoundary with a recoverable fallback, so a render throw in any step degrades to a contained, dismissible error inside the RHP instead of crashing the app. We already use this exact pattern to contain a risky subtree in MapView.web.tsx:

App/src/components/MapView/MapView.web.tsx

Lines 34 to 44 in be8591c

	return (
	<ErrorBoundary
	resetKeys={[errorResetKey]}
	fallback={
	<PendingMapView
	title={isOffline ? translate('distance.mapPending.title') : translate('distance.mapPending.errorTitle')}
	subtitle={isOffline ? translate('distance.mapPending.subtitle') : translate('distance.mapPending.errorSubtitle')}
	style={styles.mapEditView}
	/>
	}
	>

Applied to ReimbursementAccountPage's render output:

<ErrorBoundary
  errorMessage="ReimbursementAccountPage crash caught by error boundary"
  fallback={
    <ScreenWrapper testID="ReimbursementAccountPage">
      <HeaderWithBackButton
        title={translate("bankAccount.addBankAccount")}
        onBackButtonPress={() => Navigation.goBack(backTo)}
      />
      <FullPageOfflineBlockingView>{errorText}</FullPageOfflineBlockingView>
    </ScreenWrapper>
  }
>
  {/* existing entry-point / step rendering */}
</ErrorBoundary>

The user stays in the app and can back out / retry, and logError still reports the underlying exception so the real throwing line surfaces in our logs/Sentry. Containment is complementary to the per-field guards from the other proposals — keep both: guard the known throw site, and stop any future throw from nuking the whole app.

What alternative solutions did you explore? (Optional)

• Only guard the specific known field (bankAccountList[key]?.accountType). Correct and minimal, and already covered by other proposals — but it fixes a single read site; a different malformed slice in any other step re-creates the same app-wide crash, so on its own it leaves the blast-radius bug in place.
• Tighten the BankAccountList type to Record<string, BankAccount | null> so the compiler forces guards at every access. Good long-term hardening, but a much broader change and still doesn't contain throws from non-list data (stale achData, corpay state, etc.).

[lorretheboy]

Proposal

What is the root cause of that problem?

When the bank-account setup screen renders, VerifiedBankAccountFlowEntryPoint builds the list of personal bank accounts by iterating BANK_ACCOUNT_LIST and reading .accountType off each entry with no null guard:

App/src/pages/ReimbursementAccount/VerifiedBankAccountFlowEntryPoint.tsx

Line 104 in a913c67

const personalBankAccounts = bankAccountList ? Object.keys(bankAccountList).filter((key) => bankAccountList[key].accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT) : [];

bankAccountList is typed as Record<string, BankAccount>, so TypeScript treats bankAccountList[key] as always-defined and never forces optional chaining. At runtime, though, an Onyx entry in the list can be null/malformed. When that happens, bankAccountList[key].accountType throws a TypeError during render → the error boundary catches it → "Uh-oh, something went wrong!". Because it only triggers for users whose BANK_ACCOUNT_LIST contains such an entry, it can't be reproduced on a clean account, matching the "Unable to reproduce" note.

The same Onyx data is accessed safely elsewhere with optional chaining, confirming the entries are not guaranteed to be present:

App/src/pages/workspace/ConnectExistingBusinessBankAccountPage.tsx

Line 57 in a913c67

if (bankAccountList && methodID && !bankAccountList[methodID]?.accountData?.policyIDs?.includes(policyID)) {

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

Guard the per-entry access in the personalBankAccounts filter so a null/undefined entry is skipped instead of crashing — use bankAccountList[key]?.accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT, consistent with the optional-chaining pattern already used in ConnectExistingBusinessBankAccountPage.

This is the single point that crashes:

App/src/pages/ReimbursementAccount/VerifiedBankAccountFlowEntryPoint.tsx

Line 104 in a913c67

const personalBankAccounts = bankAccountList ? Object.keys(bankAccountList).filter((key) => bankAccountList[key].accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT) : [];

What alternative solutions did you explore? (Optional)

Tighten the BankAccountList type to Record<string, BankAccount | null> so the compiler flags every unguarded access (including this one) across the codebase, then add optional chaining where needed. Broader and safer long-term, but a much larger change than the targeted one-line guard.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.