Report - After bulk duplicating outstanding expenses offline, two new reports are created

[jponikarchuk]

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.58-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: #84657
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has at least one workspace.
Prerequisite 2: Delayed submissions and approvals enabled.

1. Open the staging.new.expensify.com website.
2. Open workspace chat.
3. Create two different manual expenses.
4. Open the just created report.
5. Click on "Submit"
6. Turn off internet connection.
7. Select both expenses.
8. Click on dropdown menu > "Duplicate Expenses"
9. Return to chat.
10. Note that two different reports were created containing the two duplicate expenses.
11. Turn on internet connection.
12. Note that one of those two new reports, disappears.

Expected Result:

After bulk duplicating outstanding expenses, only one new report should be created with the duplicates.

Actual Result:

After bulk duplicating outstanding expenses while offline, two different reports are created containing the duplicates. One of those reports disappear when recovering internet connection.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[OSBotify]

Investigation Summary - Frontend bug. Causing PR: #84657 High confidence. Recommendation: REVERT. PR 84657 introduced the bulk duplication feature. Offline behavior creates two separate optimistic IOU reports instead of one. Root cause is in bulkDuplicateExpenses where the currentTargetReport patch on line 1028 only fires when iouReportID is falsy. When the expense chat already has an iouReportID the condition never triggers and the shared optimisticIOUReportID is not threaded through subsequent iterations, causing two reports to be created offline, one of which disappears on reconnect. Assigned: @Krishna2323 (author), @situchan (reviewer), @JS00001 (reviewer). Labels: DeployBlockerCash kept.

[MelvinBot]

Proposal

Problem: bulkDuplicateExpenses runs a synchronous for loop calling duplicateExpenseTransaction for each selected transaction. Each call triggers API.write → Onyx.update(optimisticData), but Onyx.update is not awaited and subscriber callbacks are deferred to the next macrotask (setTimeout(0)). The module-level allReports variable in IOU/index.ts is only refreshed when the Onyx collection callback fires — which happens after the entire loop completes.

So when iteration 2 runs, getMoneyRequestInformation looks up the optimistic IOU report from iteration 1 via allReports[chatReport.iouReportID] and gets null (stale state), causing it to create a second IOU report.

Root Cause: Race condition between synchronous loop execution and asynchronous Onyx state propagation in Duplicate.ts:995-1026.

Solution: Instead of relying on the Onyx lookup to find the IOU report created by the first iteration, pass the optimistic IOU report object directly to subsequent iterations. After the first call to duplicateExpenseTransaction creates a new IOU report, capture that report and pass it as the existingIOUReport parameter for all subsequent iterations. This avoids the Onyx lookup entirely and keeps everything synchronous.

Specifically, in bulkDuplicateExpenses, after the first iteration creates the IOU report optimistically, track that report and feed it into getMoneyRequestInformation for the remaining iterations so shouldCreateNewMoneyRequestReport is false.

Evidence chain

1. Loop is synchronous — Duplicate.ts:995-1026 iterates transactionsToDuplicate in a for loop
2. Onyx.update not awaited — API/index.ts:79-82 calls Onyx.update(optimisticData) without await
3. Subscriber deferred — Onyx's prepareSubscriberUpdate uses setTimeout(0) to batch notifications (OnyxUtils.js:622-632)
4. allReports stale — IOU/index.ts:732-738 updates allReports only on Onyx callback, which fires after the loop
5. Lookup returns null — IOU/index.ts:2506-2507 looks up allReports[chatReport.iouReportID] → null → creates new report
6. Two reports created optimistically, one disappears when server reconciles on reconnect

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.