[Due for payment 2026-06-19] [Due for payment 2026-06-18] Expense - Report RHP closes after saving attendees

[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.4.5-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92161
Email or phone of affected tester (no customers): sdjoisndjodnsdjodisdo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Enable Rules.
• Enable Attendee tracking in Rules settings.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Open the report.
5. Click Attendees.
6. Click Save.

Expected Result:

Report RHP will not close after saving attendees.

Actual Result:

Report RHP closes after saving attendees.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7177541_1781148325558.15.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7177541

[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/efbed21f3b27b85bfe7ef8555070c44ce532e1f40fc5df2067231190f51ed744

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #92161

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 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:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

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

When editing Attendees on an existing expense from the Report RHP (Rules + Attendee tracking enabled), tapping Save closes the entire Report RHP instead of returning to the expense view inside the RHP. Regression from #92161 (migrate money request part 2), which migrated the Attendees flow to the dynamic-routes system. This is the linked deploy blocker.

What is the root cause of that problem?

The migrated page now passes an explicit fallback route to goBack, whereas it previously passed nothing.

• The page computes a back path by stripping the dynamic suffix off the current URL and calls Navigation.goBack(backPath):
  • DynamicIOURequestStepAttendeesPage.tsx:58, :88 (Save), :110 (back button)
• From the Report RHP, the underlying screen is EXPENSE_REPORT, which was opened with a backTo param. The stripped back path (e.g. e/<reportID>) has no backTo.
• Passing a route into goBack routes through goUp, which compares route params. backTo is not in the ignore list (Navigation.ts:348), so the synthesized {reportID} ≠ the live {reportID, backTo} → no match → goUp falls into the REPLACE branch on the wrong target, tearing down the RHP instead of popping just the Attendees screen.
• Before the PR, MoneyRequestView opened Attendees with no backTo and the page called Navigation.goBack(undefined), which hits the plain-pop path (Navigation.ts:533) and cleanly removed only the Attendees modal.

The create/confirmation-step entry point (AttendeeField) doesn't break because Attendees is pushed within the same MONEY_REQUEST modal stack directly above STEP_CONFIRMATION, whose params match deterministically, so goUp resolves to a clean pop.

Supporting evidence

• createDynamicRoute appends the suffix to Navigation.getActiveRoute() → e/<reportID>/money-request/attendees/edit/...
• useDynamicBackPath strips that suffix back to e/<reportID> (no backTo): useDynamicBackPath.ts:33-39
• goBack(backToRoute) → goUp vs no-arg plain pop: Navigation.ts:511-534
• Attendee route + entryScreens (RIGHT_MODAL.EXPENSE_REPORT is an entry screen): ROUTES.ts:238-255

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

Restore the pre-PR behavior for this page: navigate back with no explicit fallback so it performs a plain stack pop, which correctly drops only the Attendees modal and reveals the underlying EXPENSE_REPORT untouched (and still returns to STEP_CONFIRMATION in the create flow).

In DynamicIOURequestStepAttendeesPage.tsx:

• Line 88: Navigation.goBack(backPath); → Navigation.goBack();
• Line 110: Navigation.goBack(backPath); → Navigation.goBack();
• Remove the now-unused backPath (line 58, useDynamicBackPath import) and its dependency in the useCallback deps array (line 106).

This should be validated against both entry points: edit-from-report (Save and back button) and the create/confirmation step.

What alternative solutions did you explore?

Adding backTo to routeParamsIgnore in Navigation.ts:348 would also make the match succeed, but it changes the global goUp contract and risks regressions in other goBack(route) callers that rely on backTo to distinguish routes. The page-local goBack() change is the safer, minimal fix for the deploy blocker.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93253) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.