Spend - RHP loads infinitelly after merging Self DM expense with workspace expense offline.

[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.0.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: #89360
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search

Action Performed:

Prerequisite: Account has Self DM.
Prerequisite 2: Account has at least one workspace.

1. Open the staging.new.expensify.com website.
2. Create an expense in self DM.
3. Create an expense in workspace chat.
4. Go to Spend > Expenses.
5. Turn off internet connection.
6. Select the workspace expense via the checkbox.
7. Click the dropdown button > Merge.
8. Select self DM expense > Continue.
9. Select the second option in each section > Next > Merge expenses.
10. Note that infinite loading is displayed when RHP is opened.

Expected Result:

After meging expense from Self DM with workspace expense while on "Spend", user should automatically land on transaction thread.

Actual Result:

After merging expense from Self DM with workspace expense while on "Expenses" section on "Spend", RHP is displayed with infinite loading.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172999_1780690780599.RHP.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7172999

[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/26b60b8eb1d62b0050c78b6fae37ace45070ecafacd480b72ccb0ca9e3b98a4c

[melvin-bot]

@MonilBhavsar recently merged #89360, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @NicolasBonet (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

[godzillaxbox19982014-lgtm]

Proposal

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

Spend - RHP loads infinitelly after merging Self DM expense with workspace expense offline.

What is the root cause of that problem?

I traced this to the path that handles workspace name, expense report, DM:

• src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:219 (existingInvoiceReport): const existingInvoiceReport = useParticipantsInvoiceReport(receiverAccountID, receiverType, senderWorkspaceID);
• src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:195 (hasViolations): const hasViolations = hasViolationsReportUtils(report?.reportID, transactionViolations, currentUserPersonalDetails.accountID, currentUserPersonalDetails.login ?? '');
• src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:217 (senderWorkspaceID): const senderWorkspaceID = transaction?.participants?.find((p) => p?.isSender)?.policyID;
• The local evidence matches this recurring failure shape: optimistic transaction/report data is written to one Onyx key but the visible list reads another derived key. Here, src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:219 and src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:195 do not agree on the same workspace name, expense report, DM value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:219 to derive workspace name, expense report, DM from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:195; that follows the safer family move to align optimistic/success/failure data with the selector consumed by the screen, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/ReportUtils*.ts for the exact issue flow: Spend - RHP loads infinitelly after merging Self DM expense with workspace expense offline..
2. Cover the counter-case near src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:219 so valid existing workspace name, expense report, DM behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep workspace name, expense report, DM consistent at the first read/write boundary shown above.