[$250] dd BA- After clicking "Update details" name is empty, user is dropped out after clicking Next

[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: 9.3.78-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/13176694/test-cases/41236766
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacBook Air 15.7.4 Chrome, iPhone 15 iOS 26.4.2
App Component: Workspace Settings

Action Performed:

1. Sign in to ND with a new account, validate the account
2. Create a workspace
3. Navigate to Workflows > Add bank account > Click "Log into your bank"
4. Select "Regions" bank and continue with plaid credentials, select saving option
5. Complete the Personal info / DOB / Address step
6. Enter company name as "Six Labs" in the Company info, complete the flow
7. On the *Let's finish in chat" modal click "Finish in chat"
8. Go to the Workspace - Workflows - click the pending bank account
9. Click "Continue setup", then "Update details"
10. First and last name fields are empty (on Chrome), enter them and click Next

Expected Result:

First and last name fields are not empty, user is able to smoothly navigate to the Company name step

Actual Result:

First and last name fields are empty, user is dropped out of updating details flow after clicking Next on the "What's your legal name" page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bandicam.2026-05-20.10-16-57-660.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7158497

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057003664748301386
• Upwork Job ID: 2057003664748301386
• Last Price Increase: 2026-05-20

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

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two bugs, both rooted in how the "Update details" flow interacts with the step-syncing logic in ReimbursementAccountPage.tsx.

1. Empty first/last name fields: When the page mounts, clearReimbursementAccountDraft() wipes the form draft. The FullName substep reads defaults from achData.firstName / achData.lastName, which are not populated by the server response for an account in VERIFYING state. Additionally, isBankAccountVerifying forces startFrom=0, so the user always lands on FullName with empty defaults.

2. Dropped from flow after clicking Next: When the user clicks Next on FullName, onNextSubStep fires submit(false), calling updatePersonalInformationForBankAccount with confirm=false. The server response returns achData.currentStep set back to VALIDATION (since the account is in VERIFYING state). The step-syncing useEffect detects that achData.currentStep (VALIDATION) differs from USDBankAccountStep (REQUESTOR) and overrides it, yanking the user back to the FinishChatCard screen.

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

1. Guard the step-syncing effect against overriding user-initiated step changes during the "Update details" flow. When the user explicitly navigates to REQUESTOR from FinishChatCard (account in VERIFYING state), the effect at line 267 should not sync USDBankAccountStep back to the server value. A flag or state variable (e.g., isUpdatingDetails) could be set when "Update details" is clicked and cleared on completion, preventing the sync effect from overriding the local step.

2. Pre-populate the form draft with personal info from achData when entering the "Update details" flow, so FullName has the correct defaults even after clearReimbursementAccountDraft() runs. This could be done in the FinishChatCard onPress handler by copying relevant achData fields into the draft before navigating to REQUESTOR.

What alternative solutions did you explore? (Optional)

• Optimistically setting achData.currentStep in the API call's optimistic data: This would prevent the mismatch, but getVBBADataForOnyx intentionally avoids setting currentStep optimistically to let the server drive step transitions. Changing this broadly could introduce regressions in other flows.
• Skipping the submit(false) call on intermediate substeps for VERIFYING accounts: This would avoid the problematic API call but would also skip saving partial progress, which may be needed.

Investigation details

Data flow triggering the bug:

1. User navigates to bank account page → clearReimbursementAccountDraft() empties form draft → OpenReimbursementAccountPage (READ) fetches data
2. Server responds with achData (without firstName/lastName for VERIFYING state) → achData.currentStep = VALIDATION
3. User clicks "Continue setup" → sees FinishChatCard
4. User clicks "Update details" → USDBankAccountStep set to REQUESTOR locally → PersonalInfo/FullName renders with empty defaults
5. User types name, clicks Next → submit(false) → UpdatePersonalInformationForBankAccount API call
6. Server response sets achData.currentStep back to VALIDATION
7. Step-syncing useEffect detects mismatch → overrides USDBankAccountStep to VALIDATION → user sees FinishChatCard again

Key code locations:

• Step sync effect: ReimbursementAccountPage.tsx:265-269
• "Update details" handler: FinishChatCard.tsx:79-84
• onNextSubStep firing API: PersonalInfo.tsx:59
• FullName defaults: FullName.tsx:19-22
• goToWithdrawalAccountSetupStep is client-only: navigation.ts:11-13

Possibly related issue: Expensify/App#91077 — "Can't complete bank account verification" — may share the same step-syncing root cause.

---

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.

[MobileMage]

Proposal

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

When a bank account is in the VERIFYING state and the user clicks "Update details" from the FinishChatCard, the first/last name fields on the "What's your legal name" page are shown empty, and after entering a name and clicking Next, the user is dropped back to the FinishChatCard instead of advancing to the next substep.

What is the root cause of that problem?

There are two intertwined root causes.

Empty name fields: FinishChatCard's "Update details" button navigates directly to CONST.BANK_ACCOUNT.STEP.REQUESTOR by setting USDBankAccountStep in local state. This renders PersonalInfo, which reads default values via getSubStepValues — first from reimbursementAccountDraft, then from reimbursementAccount?.achData. In PersonalInfo.tsx, when isBankAccountVerifying is true, startFrom is forced to 0 (the FullName substep), ignoring any existing data. The FullName substep then reads reimbursementAccount?.achData?.firstName and achData?.lastName directly (not via getSubStepValues). On re-entry after the "Finish in chat" flow, the draft (REIMBURSEMENT_ACCOUNT_FORM_DRAFT) was cleared when the user left the REQUESTOR step, and the draft is never re-seeded from achData because the draftStep useEffect in ReimbursementAccountPage (line 308-310) short-circuits early with if (shouldShowContinueSetupButton) { return; } — preventing the updateReimbursementAccountDraft(getBankAccountFields(getFieldsForStep(draftStep))) call from ever running while shouldShowContinueSetupButton is true.

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 308 to 327 in 42e9c77

	if (shouldShowContinueSetupButton) {
	return;
	}
	const currentStepRouteParam = getStepToOpenFromRouteParams(route, hasConfirmedUSDCurrency);
	if (currentStepRouteParam === currentStep) {
	// If the user is connecting online with plaid, reset any bank account errors so we don't persist old data from a potential previous connection
	if (currentStep === CONST.BANK_ACCOUNT.STEP.BANK_ACCOUNT && achData?.subStep === CONST.BANK_ACCOUNT.SETUP_TYPE.PLAID) {
	hideBankAccountErrors();
	}
	// The route is showing the correct step, no need to update the route param or clear errors.
	return;
	}
	// Update the data that is returned from back-end to draft value
	const draftStep = reimbursementAccount?.draftStep;
	if (draftStep) {
	updateReimbursementAccountDraft(getBankAccountFields(getFieldsForStep(draftStep)));
	}

User dropped out after clicking Next: After entering the name and submitting, onNextSubStep fires and calls updatePersonalInformationForBankAccount(bankAccountID, values, policyID, false). On success, the server responds and may update achData.currentStep back to VALIDATION. The useEffect at line 265 in ReimbursementAccountPage syncs USDBankAccountStep with achData.currentStep whenever they differ: if (USDBankAccountStep !== null && achData.currentStep !== USDBankAccountStep) { setUSDBankAccountStep(achData.currentStep) }. Since achData.currentStep is VALIDATION and USDBankAccountStep is REQUESTOR, this resets USDBankAccountStep to VALIDATION, re-rendering ConnectBankAccount with FinishChatCard — dropping the user out.

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 265 to 269 in 42e9c77

	// Sync USDBankAccountStep state with achData.currentStep when backend data changes.
	// This keeps state updated for legitimate step transitions while preventing flicker during transient re-renders.
	if (!isNonUSDSetup && USDBankAccountStep !== null && achData?.currentStep && achData.currentStep !== USDBankAccountStep) {
	setUSDBankAccountStep(achData.currentStep);
	}

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

Fix 1 — Seed the draft before entering "Update details": In FinishChatCard.tsx, before calling setBankAccountSubStep and setUSDBankAccountStep, explicitly call updateReimbursementAccountDraft(getBankAccountFields(getFieldsForStep(CONST.BANK_ACCOUNT.STEP.REQUESTOR))) to populate the draft with existing achData values. Since FinishChatCard already receives reimbursementAccount as a prop, this data is available. Alternatively, move the draft-seeding logic in ReimbursementAccountPage's useEffect so that it runs regardless of whether shouldShowContinueSetupButton is true — the early return at line 308 should be moved below the draftStep hydration block.

Fix 2 — Prevent spurious USDBankAccountStep resets during "Update details": The sync at line 267 (if (USDBankAccountStep !== null && achData.currentStep !== USDBankAccountStep)) is too aggressive — it fires whenever the server achData.currentStep disagrees with the local step, even when the user is intentionally editing a prior step. Introduce a local ref or flag (e.g., isEditingPersonalInfo) that gets set when the user clicks "Update details" and cleared when they finish the REQUESTOR flow. Guard the sync block with !isEditingPersonalInfo so that intermediate updatePersonalInformationForBankAccount calls do not pull the user out of the REQUESTOR substep. The flag should be passed down into FinishChatCard (set on press) and cleared in PersonalInfo's completion callback.

The simplest single-point fix that addresses both symptoms is to move the if (shouldShowContinueSetupButton) { return; } guard in ReimbursementAccountPage to below the draftStep hydration block, and to add an isManuallyEditingStep boolean to the existing USDBankAccountStep sync guard. No new components are needed.

What alternative solutions did you explore? (Optional)

N/A

[Abdulloh0109]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-20 07:49:09 UTC.

Proposal

What is the root cause of that problem?

I traced this as a single race between the user's local step (driven through FinishChatCard) and the server-driven step-sync useEffect — manifested twice: once as empty inputs, once as the user being yanked back to FinishChatCard.

After step 5 of the repro the personal info was already submitted; the bank account moves to state = VERIFYING server-side and achData.currentStep is pinned to VALIDATION going forward — the server treats the account as "you're past Requestor, go validate". The OPEN_REIMBURSEMENT_ACCOUNT_PAGE response that arrives when the user returns from chat carries that state.

The "Update details" handler at FinishChatCard.tsx lines 76–87 is purely a local move backwards — it just calls setUSDBankAccountStep(REQUESTOR) and a client-only goToWithdrawalAccountSetupStep. The server is not told. Two effects then collide:

1. Inputs render empty. The draft-rehydration block at ReimbursementAccountPage.tsx lines 322–327 — the place that calls updateReimbursementAccountDraft(getBankAccountFields(getFieldsForStep(draftStep))) to seed the form draft from achData — sits below the early return at line 308. While the user is parked on FinishChatCard, shouldShowContinueSetupButton is true and that effect bails out before reaching the hydration line. When the user crosses into the local REQUESTOR step via "Update details", the effect's dependency set doesn't include USDBankAccountStep, so the hydration line never runs for the REQUESTOR fields — the draft remains the empty object that line 240 wrote at mount.

2. User is "dropped out" on Next. When the user types and submits, PersonalInfo.submit(false) fires updatePersonalInformationForBankAccount. The server response is computed against state = VERIFYING and returns achData.currentStep = VALIDATION again. The step-sync useEffect at ReimbursementAccountPage.tsx lines 265–269 only checks for inequality between achData.currentStep and the local USDBankAccountStep — it does not check direction. Per CONST.BANK_ACCOUNT.STEP, REQUESTOR is position 3, VALIDATION is position 7. The user is intentionally behind the server. The unconditional setUSDBankAccountStep(achData.currentStep) blindly pushes them back to VALIDATION, which renders FinishChatCard again — that is the "dropped out" symptom.

So the underlying bug is not in FullName's defaults: it is that the existing draft-hydration entry point doesn't fire for a user-initiated backward step transition, and the sync entry point only treats the server step as authoritative.

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

Two surgical changes, both in the page-level state machine — not in FullName:

1. Make the step sync direction-aware. At ReimbursementAccountPage.tsx line 267 change the guard so the local step is only reassigned when the server step is strictly later in the CONST.BANK_ACCOUNT.STEP ordering than the local step. A small ordered-step index helper (or Object.values(STEP).indexOf(...) comparison) is enough. The semantic this encodes: "the server can push us forward, but the user is allowed to navigate backwards via the FinishChatCard menu without being overridden". This kills the "dropped out" symptom without introducing any extra flag, ref, or session state.

2. Hydrate the draft at the press, not via the page-level effect. In FinishChatCard.tsx lines 79–84, before setBankAccountSubStep(...).then(...), call updateReimbursementAccountDraft(getBankAccountFields(getFieldsForStep(CONST.BANK_ACCOUNT.STEP.REQUESTOR))) — reusing the very same helper combination used at line 326. This seeds the draft with whatever the BE returned for the Requestor fields exactly at the moment the user transitions into that step. Because the form provider already reads its defaults from REIMBURSEMENT_ACCOUNT_FORM_DRAFT, FullName (and its siblings: DateOfBirth, Address, SSN) all pick the values up unmodified — no per-subStep code changes.

Together: (1) keeps the user inside Requestor while they edit; (2) makes sure they edit pre-filled values instead of blanks.

What alternative solutions did you explore? (Optional)

• Move the line-308 shouldShowContinueSetupButton early return below the hydration block. This would let updateReimbursementAccountDraft(...) fire whenever the page-level effect runs, but the effect runs on many re-renders unrelated to the user pressing "Update details" — it can overwrite a draft the user has just edited (e.g. if an unrelated Onyx merge re-fires the effect mid-typing). Targeted hydration at the user's press avoids that footgun.
• Introduce an isUpdatingDetails ref to suppress the line-267 sync only during the Update details flow. Works, but the lifetime is ambiguous — when do you clear it? Across re-mounts? On submit success? On any back-button? A direction-aware ordering check is bound to the actual condition that distinguishes "server is ahead of me" from "server is behind me", which is the real invariant.

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.

[dilshodmackbook-sketch]

Proposal (updated)

Thanks for the review @QichenZhu — you're right that the legal-name → DOB hand-off in my first proposal is incomplete. The two fixes I had (sync-guard + seeded firstName/lastName) stop the eject and pre-fill the name inputs, but they leave a third symptom: when the user clicks Next on the legal-name screen, the DOB substep mounts inside the same React Navigation screen (useSubStep only swaps screenIndex), so the DatePicker's autoFocus — which is driven by useAutoFocusInput on top of useFocusEffect / transitionEnd — never fires the real navigation event and the picker stays closed. The picker only ever auto-opens after a real screen transition, which doesn't happen mid-useSubStep.

What is the root cause of that problem?

Root cause is the same as before, plus one extra: the "Update details" entry seeds only firstName and lastName into the draft, and PersonalInfo then forces the user back to the FullName substep regardless of what's already in achData:

https://github.com/Expensify/App/blob/main/src/pages/ReimbursementAccount/USD/Requestor/PersonalInfo/PersonalInfo.tsx#L48-L49

Because isBankAccountVerifying short-circuits getInitialSubStepForPersonalInfo, the user always starts on FullName even though the BE has every Requestor field for them already. That forces a useSubStep → DOB substep transition for the Next press, and that's the transition where DatePicker's autoFocus silently no-ops (no transitionEnd ever lands; the 1000ms SCREEN_TRANSITION_END_TIMEOUT fallback gets reset by the re-render that the updatePersonalInformationForBankAccount response triggers, so setIsScreenTransitionEnded(true) never wins the race).

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

Three changes, all in the two files I already touched:

1. Guard the sync effect against overriding the FE step while the account is verifying (same as before):

-        if (!isNonUSDSetup && USDBankAccountStep !== null && achData?.currentStep && achData.currentStep !== USDBankAccountStep) {
+        const isBankAccountVerifying = achData?.state === CONST.BANK_ACCOUNT.STATE.VERIFYING;
+        if (!isNonUSDSetup && !isBankAccountVerifying && USDBankAccountStep !== null && achData?.currentStep && achData.currentStep !== USDBankAccountStep) {
             setUSDBankAccountStep(achData.currentStep);
         }

https://github.com/Expensify/App/blob/main/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx#L265-L269

2. Seed the entire Requestor draft (not just names) on the "Update details" press — reuse getFieldsForStep('Requestor') so firstName, lastName, dob, ssnLast4, and the requestor address all land in REIMBURSEMENT_ACCOUNT_FORM_DRAFT together:

 onPress={() => {
+    updateReimbursementAccountDraft(
+        lodashPick(reimbursementAccount?.achData, getFieldsForStep(CONST.BANK_ACCOUNT.STEP.REQUESTOR)),
+    );
     setBankAccountSubStep(CONST.BANK_ACCOUNT.SETUP_TYPE.MANUAL).then(() => {
         setUSDBankAccountStep(CONST.BANK_ACCOUNT.STEP.REQUESTOR);
         goToWithdrawalAccountSetupStep(CONST.BANK_ACCOUNT.STEP.REQUESTOR);
     });
 }}

https://github.com/Expensify/App/blob/main/src/pages/ReimbursementAccount/USD/ConnectBankAccount/components/FinishChatCard.tsx#L76-L87

3. Drop the isBankAccountVerifying ? 0 override in PersonalInfo so getInitialSubStepForPersonalInfo(values) is allowed to do its job — once #2 has filled the draft, that helper returns 4 (Confirmation) when the BE already has every Requestor field (the case in this repro after step 6), and a smaller index only if a field is genuinely missing:

-    const startFrom = useMemo(() => (isBankAccountVerifying ? 0 : getInitialSubStepForPersonalInfo(values)), [values, isBankAccountVerifying]);
+    const startFrom = useMemo(() => getInitialSubStepForPersonalInfo(values), [values]);

https://github.com/Expensify/App/blob/main/src/pages/ReimbursementAccount/USD/Requestor/PersonalInfo/PersonalInfo.tsx#L48-L49

Together: (1) keeps the user inside Requestor during the API round-trip, (2) hands every saved value back to the form, (3) lets them land on the Confirmation summary where they can onMove(...) into any individual substep they actually want to edit. The DOB substep then only mounts via an explicit user press (the Confirmation row), which is a fresh useSubStep mount where DatePicker's autoFocus reaches the input via the timeout fallback before any racing Onyx merge — the picker pops as expected.

What alternative solutions did you explore? (Optional)

• Keep the forced startFrom = 0 and instead patch DatePicker to open its modal from a useEffect on mount when autoFocus is true. Rejected: DatePicker is shared across many flows (workspace member profile, expense date, money request, etc.) and they all rely on useAutoFocusInput's priority-arbiter + window-ready gating; opening the modal from a raw mount effect would bypass tryClaim(Priorities.AUTO) / isWindowReadyToFocus() and could pop the picker mid-screen-transition in unrelated flows. The substep-transition gap is the actual problem, not DatePicker.
• Move the draft hydration into ReimbursementAccountPage by dropping the if (shouldShowContinueSetupButton) return; early-return above the draftStep hydration block. Rejected: that effect fires on many unrelated Onyx merges; making it run while shouldShowContinueSetupButton is true would overwrite a draft the user has just edited (e.g. they typed a new last name and an unrelated reimbursementAccount merge re-fires the effect mid-typing). Seeding at the press in FinishChatCard only runs once at the boundary the user actually crosses.
• Optimistically set achData.currentStep = 'Requestor' in setBankAccountSubStep's optimistic data. Rejected: it mutates synchronised BE state for a verifying account and would mislead every other currentStep consumer (route resolution, getInitialCurrentStep, validation gating).

[melvin-bot]

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

[kamronbek04]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.