[Due for payment 2026-08-07] Expense - RHP back button on confirm page changes report from expense thread to self DM

[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.43-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96136
Email or phone of affected tester (no customers): applausetester+sdodjsoddddds@applause.expensifail.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:

• Log in with Expensifail account.
• Account does not have workspace.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create an expense.
4. Open the expense.
5. Click on the header.
6. Click Submit to my employer.
7. On confirm page, click RHP back button.

Expected Result:

RHP will close without changing the currently opened report.

Actual Result:

RHP closes and central pane opens self DM.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7214962_1784758422890.3.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @hungvu193

Issue Owner

Current Issue Owner: @mallenexpensify

[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/68b22a1dc31dd83e2b25499307abcfb491925aaa739d1568c29e50b71b686248

[melvin-bot]

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

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

Issue Analysis

Root Cause: In the zero-workspace "Submit to my employer" flow, the confirmation route is opened with an explicit backTo pointing at the self-DM (the origin chat), baked in at ReportUtils.ts:11686-11688. The RHP back button runs navigateBack → Navigation.goBack(backTo). Because the self-DM is not the report currently under the RHP (the expense thread is), goUp can't find it in the stack and dispatches a REPLACE — swapping the expense thread for the self-DM in the central pane. That is exactly the reported symptom.

This backTo-to-self-DM was added for the narrow-layout case (issue #96117): there the RHP is fullscreen over an un-renderable draft-workspace report, so backing out needs an explicit destination. On wide layout the origin expense thread is already sitting under the RHP, so forcing a backTo replace is wrong.

Important: the recently-merged PR #96136 (which auto-assigned you) did not introduce this path — its fix #5 only touched the narrow-layout pre-insert readiness check, which is gated behind getIsNarrowLayout() and never runs on wide layout. The backTo=self-DM logic predates #96136 (from the original "Submit to my employer" feature). Reverting #96136 will not fix this and would reintroduce the narrow-layout infinite-skeleton bug (#96117).

Recommended Fix: Make the back destination layout-aware so it only forces the self-DM backTo on narrow layout:

• Preferred: in createDraftWorkspaceAndNavigateToConfirmationScreen, only set backTo when getIsNarrowLayout() is true; pass undefined on wide layout so navigateBack simply dismisses the RHP and reveals the expense thread already underneath.
• Alternative: in navigateBack, on wide layout ignore backTo when the report currently under the RHP is still valid (Navigation.getTopmostReportId() matches) and goBack()/dismissModal() instead.

Investigation details & evidence chain

1. User opens the expense → central pane shows the transaction-thread (expense) report.
2. Header → details → "Submit to my employer" resolves the origin via getOriginalReportID, which walks the expense thread up to its parent self-DM, so backToReportID = self-DM.
3. Zero workspaces → createDraftWorkspaceAndNavigateToConfirmationScreen(..., backToReportID = self-DM) opens the confirmation RHP with backTo = ROUTES.REPORT_WITH_ID.getRoute(self-DM) (ReportUtils.ts:11686-11688). The RHP is pushed on top of the expense thread, which remains underneath.
4. RHP back button → navigateBack sees backTo set → Navigation.goBack(backTo) (IOURequestStepConfirmation.tsx:705-707).
5. goUp finds the self-DM is not in the current stack → dispatches REPLACE, swapping the expense thread for the self-DM in the central pane.

Alternative explanations ruled out: the wide-layout pre-insert path is a non-factor — the entire pre-insert effect early-returns on !getIsNarrowLayout() (line 550), so PR #96136's {} readiness change cannot affect wide layout. gh pr diff 96136 confirms the PR touched neither backTo, navigateBack, nor goBack.

Confidence: High — code evidence forms a complete chain and matches the reported symptom (expense thread → self-DM on wide layout). Not confirmed on a running build.

---

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

[iwiznia]

This is behind a beta, so not a blocker