[Due for payment 2026-08-05] Expense - Expense report RHP closes after clicking Save on Attendees RHP

[applause-bot]

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-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: #95930
Email or phone of affected tester (no customers): jomisjndojsidosnj@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.

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

Expected Result:

Expense report RHP will not close after clicking Save on Attendees RHP.

Actual Result:

Expense report RHP closes after clicking Save on Attendees RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

_

Bug7219233_1785188602345.8.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7219233

Issue Owner

Current Issue Owner: @suneox

[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/5e65e54b3360fb633b0253fbc083345485950f348261151fdc17ca4ac75ca856

[melvin-bot]

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

[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]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #95930 - "migrate money request part 2" by @huult (High confidence)
Related Issues: none

Recommendation: REVERT

PR #95930 replaced the explicit backTo navigation param on the Attendees step with a URL-derived backPath from the new useDynamicBackPath hook. When Attendees is opened from the expense report RHP (the repro flow), that derived path resolves to the underlying report route, so saving dismisses the whole RHP modal instead of returning one step to the expense details view. Reverting is the cleanest fix; if a targeted fix is preferred, see the concrete pointer below.

Assigned: @huult (PR author), @mjasikowski and @suneox (approving reviewers) from the highest-confidence causing PR only
Labels: No changes. Kept DeployBlockerCash (App deploy is blocked by an App PR). No DeployBlocker label was present, so nothing to remove.

📋 Detailed Analysis

Evidence

• The issue is a new regression on staging (9.4.45-0), not reproducible on production, so the cause is a PR in the current StagingDeployCash #97134 checklist.
• PR migrate money request part 2 #95930 (merged 2026-07-24, in this staging deploy) is titled "migrate money request part 2" and directly modifies the exact affected code path: it renames IOURequestStepAttendees.tsx → DynamicIOURequestStepAttendees.tsx, changes MoneyRequestView.tsx (the expense detail RHP that opens Attendees), and rewrites the Attendees route/navigation config.
• The PR's own QA steps only cover opening Attendees from the confirmation step of the Create Expense flow ("On the confirmation step, tap Attendee"). It does not cover opening Attendees from an already-created expense's detail RHP (the exact repro path in this issue), which is why the regression slipped through.

Verification

Affected files confirmed modified by #95930:

• src/pages/iou/request/step/DynamicIOURequestStepAttendees.tsx (renamed from IOURequestStepAttendees.tsx)
• src/components/ReportActionItem/MoneyRequestView.tsx (opens the Attendees step from the expense RHP)
• src/ROUTES.ts, src/libs/Navigation/linkingConfig/config.ts, src/libs/Navigation/linkingConfig/OldRoutes.ts

The regressing change in DynamicIOURequestStepAttendees.tsx:

Before (used an explicit caller-provided back target):

params: {transactionID, reportID, iouType, backTo, action},
// ...
Navigation.goBack(backTo, {shouldSkipFocusRestore: true});   // in saveAttendees
Navigation.goBack(backTo);                                    // in navigateBack

After (PR #95930 — derives the back target from the current URL):

params: {transactionID, reportID, iouType, action},          // backTo removed
const backPath = useDynamicBackPath(DYNAMIC_ROUTES.MONEY_REQUEST_ATTENDEE.path);
// ...
Navigation.goBack(backPath, {shouldSkipFocusRestore: true}); // in saveAttendees
Navigation.goBack(backPath);                                 // in navigateBack

Root Cause

MoneyRequestView opens Attendees from the expense detail RHP via
Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.MONEY_REQUEST_ATTENDEE.getRoute(EDIT, iouType, transactionID, reportID))).
createDynamicRoute appends attendees?... to Navigation.getActiveRoute(), producing a URL like /r/<reportID>/attendees?action=edit&iouType=...&transactionID=...&reportID=....

On Save, useDynamicBackPath(MONEY_REQUEST_ATTENDEE.path) strips the attendees suffix (via getPathWithoutDynamicSuffix) and returns /r/<reportID> — the report route, which lives outside the RHP. Navigation.goBack('/r/<reportID>') therefore tears down the entire RHP modal stack and dumps the user back to the workspace chat, instead of popping a single step back to the expense details view.

The old backTo param pointed at the specific RHP screen to return to; the URL-derived backPath does not account for the RHP nesting (note that MONEY_REQUEST_ATTENDEE.entryScreens includes SCREENS.RIGHT_MODAL.EXPENSE_REPORT, so this Attendees step is expected to be reachable from inside the expense RHP). The sibling Tax steps migrated in the same PR use the identical useDynamicBackPath pattern, so they should be re-verified from the expense RHP as well.

Fix pointers:

• Revert (recommended default): cleanly revert migrate money request part 2 #95930 to restore the explicit backTo-based navigation.
• Targeted roll-forward alternative: in src/pages/iou/request/step/DynamicIOURequestStepAttendees.tsx (lines 45, 102, 127), the useDynamicBackPath-derived backPath needs to resolve to the expense RHP screen rather than the bare /r/<reportID> report route — i.e. useDynamicBackPath / getPathWithoutDynamicSuffix must preserve the RHP context when the entry screen is RIGHT_MODAL.EXPENSE_REPORT, or the step should fall back to the explicit backTo for RHP entry points.

[MelvinBot]

Proposal

Root Cause: PR #95930 ("migrate money request part 2") changed the Attendees step to derive its "go back" target from the current URL instead of the explicit backTo param. When Attendees is opened from the expense report RHP, that derived path resolves to the underlying report route (/r/<reportID>), so saving dismisses the whole RHP modal instead of returning one step to the expense details view. High confidence — the causing PR is confirmed and on the current staging deploy.

What is the root cause of that problem?

The expense detail RHP opens Attendees via createDynamicRoute(...) in MoneyRequestView.tsx:1507, which appends attendees?... onto the active route, producing a URL like /r/<reportID>/attendees?....

On Save, the migrated step calls Navigation.goBack(backPath, ...) where backPath comes from useDynamicBackPath(...). That hook strips the attendees suffix via getPathWithoutDynamicSuffix.ts:18 and returns /r/<reportID> — the report route, which lives outside the RHP. Navigation.goBack('/r/<reportID>') therefore tears down the entire RHP modal stack and dumps the user back to the workspace chat.

Before this PR, the step used an explicit backTo param pointing at the specific RHP screen to return to; the URL‑derived backPath does not account for RHP nesting, even though MONEY_REQUEST_ATTENDEE.entryScreens includes SCREENS.RIGHT_MODAL.EXPENSE_REPORT. This is why it reproduces only when opening Attendees from an already‑created expense's detail RHP — the flow the PR's QA didn't cover.

Evidence & verification

• New regression on staging (9.4.45‑0), not reproducible on production → cause is a PR in the current StagingDeployCash Expensify/App#97134 checklist.
• PR migrate money request part 2 #95930 is on that deploy and directly rewrites the affected code path: it renamed IOURequestStepAttendees.tsx → DynamicIOURequestStepAttendees.tsx, changed MoneyRequestView.tsx (the expense RHP that opens Attendees), and rewrote the Attendees route/navigation config.
• The regressing change — the save/back handlers switched from Navigation.goBack(backTo) to Navigation.goBack(backPath) at DynamicIOURequestStepAttendees.tsx:102 and :127, with backTo removed from the route params.
• The sibling Tax steps migrated in the same PR use the identical useDynamicBackPath pattern, so they should be re‑verified from the expense RHP as well.

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

Recommended: revert #95930 — it's a deploy blocker and reverting cleanly restores the explicit backTo‑based navigation.

If a targeted roll‑forward is preferred instead of a revert: make the Attendees step resolve back to the expense RHP screen rather than the bare /r/<reportID> report route when its entry screen is RIGHT_MODAL.EXPENSE_REPORT — i.e. have useDynamicBackPath / getPathWithoutDynamicSuffix preserve the RHP context for RHP entry points, or fall back to the explicit backTo there. Re‑verify the Tax steps from the same PR under the same flow.

What alternative solutions did you explore? (Optional)

Considered whether another staging PR could cause an over‑dismiss on Save, but no other PR on this deploy touches the Attendees step or MoneyRequestView's open path — the navigation change in #95930 fully explains the symptom on all affected platforms.

---

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

[huult]

Checking