Repository navigation
Expense-Navigation loop when selected a recipient, navigated back to Amount and tapped Next #97266
Description
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.45-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96485
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.5.2, iPhone 15 iOS 26.5.2
App Component: Money Requests
Action Performed:
- Sign in to ND with a new gmail account, selecting "Something else" purpose (no workspaces in the account)
- Start chat with an existing user, send a message
- Click FAB - Create expense - Manual
- Enter an amount and click Next
- Select an account from Recents section
- Click Back button two times to navigate to the Amount
- Click Next button
Expected Result:
Step 6 - User should be navigated to the Amount screen right after clicking Back on the Confirm details
Step 7 - User should be navigated to the Confirm details page after clicking Next on the Amount page
Actual Result:
Step 6 - User is navigated to the Choose recipient screen after clicking Back on the Confirm details
Step 7 - User is navigated to the Choose recipient page after clicking Next on the Amount page second time, there is no Next button. So User can only navigate back to the Amount and forth to the Recipient
Workaround:
Unknown
Platforms:
- Android: App
- Android: mWeb Chrome
- iOS: App
- iOS: mWeb Safari
- iOS: mWeb Chrome
- Windows: Chrome
- MacOS: Chrome Safari
Screenshots/Videos
Bug7220092_1785258545527.Web_navigation.mp4
Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7220092
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~022082183479833379285
- Upwork Job ID: 2082183479833379285
- Last Price Increase: 2026-07-28
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
applause-bot commentedon Jul 28, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/f5565494008b6aa97700c3a25dd8305edef2846ab11a29b4a3a713e66044b4b4
MelvinBot commentedon Jul 28, 2026
Proposal
What is the root cause of that problem?
Starting an expense via FAB → Create expense → Manual launches the global create flow (
iouType = CREATE,isFromGlobalCreate = true) — even when you're inside an existing chat, the chat is not treated as the recipient. This makes the flow Amount → Participants ("Choose recipient") → Confirmation, and back-navigation retraces through Participants:iouType === CREATEfrom the "auto-assign the participant from the report and skip to Confirmation" branch, so it always routes to the Participants page.isFromGlobalCreate && !participantsAutoAssigned. Because a recipient chosen manually in the Participants step never setsparticipantsAutoAssigned = true, Back routes to Participants rather than doing a plaingoBack().Net effect: Amount ↔ Participants ↔ Confirmation. Back from Confirm lands on "Choose recipient", and since the Participants page is a selector with no explicit Next button, you advance only by re-picking a recipient — which reads as an inescapable loop.
What changes do you think we should make in order to solve the problem?
When a recipient is selected in the Participants step during the CREATE flow, mark the transaction so the Confirmation Back handler treats the participant as assigned (i.e. set
participantsAutoAssigned/ pass it on the confirmation route ingoToNextStep). Then Back from Confirmation does a plaingoBack()to the Participants step and, from there, back to Amount — matching the forward path and removing the "no Next button" loop. The Amount → Participants → Confirmation ordering for global create is intentional (see the code comment), so the fix is making the back path symmetric, not skipping the participants step.Investigation details & code references
Inspected at App
main@8277510.ExpenseMenuItem.tsx:38→MoneyRequest.ts:466-471(isFromFloatingActionButton→isFromGlobalCreate).IOUAmountSubmission.ts:563(iouType !== CONST.IOU.TYPE.CREATE), falling through tosubmitGlobalCreate→ participants page (IOUAmountSubmission.ts:463-484).useParticipantSubmission.ts:394-402.isFromGlobalCreate && !participantsAutoAssigned:IOURequestStepConfirmation.tsx:627-670.Alternatives considered: (a) auto-assign the chat you started from as the recipient so the CREATE flow skips Participants entirely (Amount → Confirmation) — larger behavioral change and arguably not what global-create intends; (b) give the Participants page an explicit Next/continue affordance — treats the symptom, not the loop.
Confidence: High on the mechanism (deterministic client-side routing, no logs needed). The exact "correct" UX (symmetric back vs. skip participants) is a product/design call for the team.
Next Steps for Contributor+ team:
To accept:
@MelvinBot implement [this](https://github.com/Expensify/App/issues/97266)to create a draft PR.To refine:
@MelvinBot <your feedback>To reject: Explain why you are rejecting Melvin's proposal.
melvin-bot commentedon Jul 28, 2026
Triggered auto assignment to Contributor-plus team member for initial proposal review - @truph01 (
External)melvin-bot commentedon Jul 28, 2026
Job added to Upwork: https://www.upwork.com/jobs/~022082183479833379285
melvin-bot commentedon Jul 31, 2026
@truph01 Whoops! This issue is 2 days overdue. Let's get this updated quick!
truph01 commentedon Aug 3, 2026
I don't think these are bugs.
@IuliiaHerets Could you ask QA team to confirm?
IuliiaHerets commentedon Aug 3, 2026
@truph01 do you want the QA team to retest this issue?
truph01 commentedon Aug 4, 2026
@IuliiaHerets No, I want to double-check the expected and actual behavior in the OP. I believe the current actual behavior described in the OP is actually correct.
21 remaining items
melvin-bot commentedon Sep 2, 2026
@truph01 Huh... This is 4 days overdue. Who can take care of this?
melvin-bot commentedon Sep 3, 2026
@truph01 Huh... This is 4 days overdue. Who can take care of this?
melvin-bot commentedon Sep 3, 2026
@truph01 Eep! 4 days overdue now. Issues have feelings too...
melvin-bot commentedon Sep 4, 2026
@truph01 Still overdue 6 days?! Let's take care of this!
melvin-bot commentedon Sep 5, 2026
@truph01 6 days overdue. This is scarier than being forced to listen to Vogon poetry!
melvin-bot commentedon Sep 8, 2026
@truph01 10 days overdue. Is anyone even seeing these? Hello?
melvin-bot commentedon Sep 10, 2026
@truph01 12 days overdue. Walking. Toward. The. Light...
melvin-bot commentedon Sep 14, 2026
This issue has not been updated in over 14 days. @truph01 eroding to Weekly issue.
melvin-bot commentedon Oct 7, 2026
This issue has not been updated in over 15 days. @truph01 eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!