Repository navigation
Wallet-After clicking BA row on confirmation and going back Add bank account unresponsive #103626
Description
Activity
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/029fbffabf56eac168d5799029d9df2e1eafd609f07cb216049aa9bce8bfbdbaYou have been assigned to this deploy blocker because you recently merged this PR: #102944
@marcochavezf @huult you have been assigned to this deploy blocker because you reviewed the offending PR: #102944
💬 A slack conversation has been started in #expensify-open-source
👋 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:
- Identify the pull request that introduced this issue and revert it.
- Find someone who can quickly fix the issue.
- Fix the issue yourself.
⚠️ Preliminary analysis (low confidence) — treat as a starting point, not a conclusion.I don't think Collect legal name and address before creating a wallet deposit account. caused this, so reverting it likely won't fix the bug. It's the only PR in Deploy Checklist: New Expensify 2026-10-08 that touches this flow. However, the code this repro runs through looks unchanged from production, so this is probably an existing bug.
Recommendation: Keep the blocker until someone checks production. If the bug reproduces there, demote it and fix it as a normal bug.
Likely mechanism
- Each sub-page is pushed as its own screen. On web, lower screens stay mounted. Clicking the bank row calls
onMove(ACCOUNT_NUMBERS)(ConfirmationStep.tsx:55-57). That pushes a second Plaid screen in edit mode (useSubPage/index.tsx:98-105). - Back on that screen hits the
pageIndex === 0branch. That branch has no edit-mode check, so it callsclearPersonalBankAccount()(AddBankAccount.tsx:171-175). This clears the Plaid data andsetupType, so every screen in the stack shows the setup view. - "Add bank account" sets
setupTypeback to Plaid (BankAccounts.ts:228-235). The hidden Plaid screen at the bottom of the stack then mounts unfocused, with no Plaid accounts. Its effect immediately clearssetupTypeagain (PlaidStep.tsx:49-55). The page drops back to the setup view, so the button looks unresponsive.
#102944 adds the Legal name and Address pages, changes
submit, and adds new confirmation rows. It doesn't change the back handler, the bank-row handler,PlaidStep,SetupMethod, oruseSubPage. Production goes through the same steps, with a shorter stack:plaid → confirmation → plaid (edit). I didn't reproduce this in the app, and QA couldn't validate production.Suggested fix (either way):
- In
handleBackButtonPress(AddBankAccount.tsx:159-177), return to confirmation whenisEditinginstead of clearing the draft. PersonalInfo.tsx:95-98 already does this. This change also fixes Back from the new Legal name and Address edit pages, which currently go back toward Plaid. - Harden
PlaidStepso it only clearssetupTypewhen the screen changes from focused to unfocused, not when a hidden screen mounts.
Next Steps: Reply with
@MelvinBot <your feedback>to refine this analysis.
- Each sub-page is pushed as its own screen. On web, lower screens stay mounted. Clicking the bank row calls
@MelvinBot, can you double-check the code and the PRs in the deploy checklist again? What makes you think this is an existing bug?
Reacted by melvin-botI re-checked every production vs. staging change and still found no staging-only cause. Every step that breaks the button runs on code that is identical on production. I couldn't reproduce it myself, so the next step is a production check.
Why I think it's pre-existing
The failure needs these four steps. Each one exists unchanged on production (
8991d02):- Clicking the bank row on the confirmation page opens the Plaid page in edit mode (ConfirmationStep.tsx:44). On production the stack is
plaid → confirmation → plaid (edit). - Back on that page hits
pageIndex === 0and callsclearPersonalBankAccount()(AddBankAccount.tsx:112-115). That empties the Plaid accounts and clearssetupType(BankAccounts.ts:382). - "Add bank account" sets
setupTypeback to Plaid (BankAccounts.ts:227). - The hidden Plaid screen at the bottom of the stack remounts unfocused with no accounts. Its effect clears
setupTypeagain (PlaidStep.tsx:49-55). This effect hasn't changed since June.
Checklist PRs I re-checked
- Collect legal name and address before creating a wallet deposit account.: It adds the Legal name and Address pages to the middle of the stack. Neither page writes the bank account draft or
setupType.skipPagesonly affects next/previous navigation, and Back returns before that code runs. Thesubmitchange only runs on the final Confirm, which isn't part of the repro. - The "Add bank account" button is a
ButtoninSetupMethod.tsx. Neither file changed. useSubPage,linkTo, andPlaidStepdidn't change.BankAccounts.tsonly addsupdateBankAccountName.- Navigation changes are limited to onboarding, validate-login, and new screen registrations. None of them affect pushing or going back in the right-hand panel.
- The
MenuItemchanges only touch accessibility labels and styles. The bank row still opens the Plaid page in the repro. WalletPageonly adds an "Edit nickname" entry.CollectDepositAccountonly swaps its loading indicator.
The only evidence for a regression is circumstantial: Collect legal name and address before creating a wallet deposit account. edits this flow, and the repro's "enter legal name and address" step only exists on staging.
To confirm on production: Wallet → Enable wallet → Add bank account → connect a bank → confirmation → click the bank row → Back → Add bank account. Based on the code, the button should do nothing there too.
I tried to reproduce this in my test environment. The account's "Validate your account" email-code step blocked me before I reached Plaid.
Fix (same either way): in
handleBackButtonPress, return to the confirmation page whenisEditingis true instead of clearing the draft.PersonalInfo.tsxalready does this. Also, only letPlaidStepclearsetupTypewhen the screen loses focus, not when a hidden screen mounts.- Clicking the bank row on the confirmation page opens the Plaid page in edit mode (ConfirmationStep.tsx:44). On production the stack is
@MelvinBot let's create a PR with the fix
Reacted by melvin-bot🤖 Draft PR created: Return to the confirmation when going back from a wallet bank account edit page
Please mark it as "Ready for review" or ask me to do that for you when it is ready for review.What it changes: Back on any edit page opened from the confirmation page now returns to the confirmation page. Before, Back cleared the draft. The edit pages are the bank account, legal name, and address pages. The fix is one guard in
handleBackButtonPressin AddBankAccount.tsx. It matches howPersonalInfohandles Back. The draft is no longer cleared, so the hidden Plaid screen can't reset the flow and freeze the "Add bank account" button.Testing: Typecheck, lint, the React Compiler check, and 61 related Jest tests pass. I couldn't run the repro in a browser because the test session showed a blank page before sign-in finished. Please run the issue's steps before marking the PR ready.
I didn't include the optional
PlaidStephardening, so the PR stays minimal.
view run · no recording available
Seems like it's niche and on production, so I'm going to demote.
Chrome / v9.5.6-5 PR:103643
Original issue not reproduced, but there is another one. When click on Back button on Choose bank account tab, tab blink and not navigate to previous step. Need to click Back button three timesbandicam.2026-10-10.21-47-57-568.mp4
Reacted by Marco ChávezChrome / v9.5.6-5 PR:103643
Original issue not reproduced, but there is another one. When click on Back button on Choose bank account tab, tab blink and not navigate to previous step. Need to click Back button three timesbandicam.2026-10-10.21-47-57-568.mp4
@MelvinBot please check if the new issue was introduced in the new changes in the pr
Reacted by melvin-botPartly. The PR adds one of the three Back clicks: Back from the edit "Choose bank account" page now goes to the confirmation page first. The other two clicks come from code that's already on main. The "blink" is most likely the original "Choose bank account" page reappearing. It looks the same as the edit page QA just left.
QA wrote "original issue not reproduced", so I assumed they followed the original steps: confirmation → click the bank row → Back. On that path:
Back click Without the PR (main) With the PR 1 Clears the draft and shows the setup page. "Add bank account" is then frozen (the original bug). Returns to the confirmation page (AddBankAccount.tsx:173-176) 2 — Skips Legal name and Address and jumps back to the first "Choose bank account" page. It looks unchanged, so the page seems to blink. 3 — Clears the draft and shows the setup page. "Add bank account" works. Why click 2 lands on an identical-looking page
- Each sub-page is its own screen in the stack. Each screen takes a snapshot of
skipPageswhen it mounts (AddBankAccount.tsx:118-133). - The confirmation screen mounts after the user has entered a legal name and address. So its snapshot skips both pages, and its
prevPagegoes straight back to the first Plaid screen (useSubPage/index.tsx:46-69). This behavior was already on main before the PR. - The Plaid data isn't cleared on this path, so that screen still shows the same account list.
Caveats:
- I couldn't play the video or reproduce the steps; the test browser session stayed blank.
- If QA reached "Choose bank account" fresh, without going through the confirmation page, the PR changes nothing on that path. Back goes to the setup page in one click there, and I found no cause for a blink.
Options:
- Keep the PR. Going from the edit page → confirmation → Choose bank account → setup is normal step-by-step Back behavior. It only looks broken because the two Plaid pages look identical.
- Make it one click. When
isEditing && pageIndex === 0, go back to the bottom Plaid screen, then callclearPersonalBankAccount()after the transition. Keep the go-back-to-confirmation behavior for the Legal name and Address edit pages. No hidden Plaid screen is left in the stack, so the original freeze stays fixed.
Can you confirm what QA sees after the first Back click? If it's the confirmation page, this explanation holds.
Next Steps: Reply with
@MelvinBot apply option 2to update the PR, or@MelvinBot <your feedback>to refine this.
view run · no recording available
- Each sub-page is its own screen in the stack. Each screen takes a snapshot of
Metadata
Metadata
Assignees
Type
Projects
- Status
If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.
Version Number: 9.5.6-4
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - Provide reasoning.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #102944
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 26.6.2 Chrome, iPhone 15 iOS 26.6.1
App Component: Other
Action Performed:
Expected Result:
Clicking "Add bank account" green button opens the connecting bank account flow
Actual Result:
After clicking BA row on confirmation page, then clicking Back button "Add bank account" button is unresponsive
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7282344_1791563652216.Add_BA_in_Wallet.mp4
View all open jobs on GitHub