[Due for payment 2026-02-03] Expense - Member's expense is moved to self workspace chat after moving it to new report

[lanitochka17]

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.3.8-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: #76000
Email or phone of affected tester (no customers): #76000
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Create a workspace and invite a member and non-admin approver to the workspace.

1. Go to staging.new.expensify.com
2. [Member] Create an expense in workspace chat.
3. [Non-admin approver] Open the expense report > Click More > Submit.
4. [Non-admin approver] Click Report > Create report.
5. [Non-admin approver] Open member and your workspace chat.
   → The expense appears in both member and your workspace chat.
6. [Member] Open your workspace chat.
   → The expense does not appear in member workspace chat.
7. [Non-admin approver] Go to Account > Troubleshoot > Clear cache and restart > Reset and refresh OR relogin.
8. [Non-admin approver] Go back to member workspace chat and your workspace chat.
   → The expense disappears from member's workspace chat and it remains in your workspace chat.

Expected Result:

When non-admin approver moves member's expense to a new report, the expense will be moved to member's workspace chat in a new report.

Actual Result:

When non-admin approver moves member's expense to a new report, the expense initially appears in both member and approver's workspace chat (Step 5).

After reset app or relogin, the moved expense only appears in approver's workspace chat.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7056775_1769209634176.4.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @dylanexpensify

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @dylanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #76000 - "Allow admin to create report on behalf of employee" by @s77rt (High confidence)
Related Issues: #75607

Recommendation: REVERT

PR #76000 introduced a new feature allowing admins to create reports on behalf of employees, but it has a critical synchronization bug. When a non-admin approver moves a members expense to a new report, the expense initially appears in both the member's and approver's workspace chat. After cache clear/relogin, the expense only remains in the approver's workspace chat, which is incorrect.

The PR was merged on 2026-01-23 at 00:52:58 UTC, and this issue was reported ~23 hours later. The timing and affected functionality match perfectly.

Labels: Keeping DeployBlockerCash (this blocks the App deploy). This is a frontend bug requiring changes to App code.

Detailed Analysis

Evidence

1. Timeline Match: PR Allow admin to create report on behalf of employee #76000 merged Jan 23 00:52 UTC, issue reported Jan 23 23:52 UTC
2. Feature Match: The bug occurs when a non-admin approver moves a member's expense to a new report, which is exactly the new feature added by PR Allow admin to create report on behalf of employee #76000
3. Bug Reproducible on Staging: Version 9.3.8-0, which includes PR Allow admin to create report on behalf of employee #76000 per the StagingDeployCash checklist
4. Not in Production: Issue notes this is a new feature that doesn't exist in production

Verification

PR #76000 modified these key files related to the bug:

• src/libs/actions/Report.ts - Changed to use ownerPersonalDetails instead of creatorPersonalDetails when building new report optimistic data
• src/pages/Search/SearchTransactionsChangeReport.tsx - Modified to determine and pass the target owner's personal details
• src/pages/iou/request/step/IOURequestStepReport.tsx - Added logic to determine owner account ID from IOU actions
• src/pages/iou/request/step/IOURequestEditReport.tsx - Updated to use owner personal details

The changes allow admins to create reports on behalf of employees by passing the employee's ownerPersonalDetails when calling createNewReport(). This causes the report to be associated with the employee's workspace chat via getPolicyExpenseChat(ownerAccountID, policyID).

Root Cause

When a non-admin approver moves a member's expense to a new report:

1. The frontend optimistically creates a new report with the member as the owner (using targetOwnerPersonalDetails)
2. The report is associated with the member's workspace chat via getPolicyExpenseChat()
3. However, there appears to be a mismatch between the optimistic frontend state and the backend response
4. The expense initially shows in both workspace chats due to optimistic update inconsistencies
5. After cache clear, only the backend state persists, showing the expense in the approver's chat instead of the member's

The bug suggests that either:

• The optimistic data is incorrectly placing the expense in multiple workspace chats, OR
• The backend is not respecting the ownerEmail parameter added in CreateAppReportParams, OR
• There's a race condition in how the parent report ID is being set for the moved transaction

[s77rt]

non-admins should not even see the option to create reports on employees expense chats. It seems I overlooked that