[$250] Expense - Expense preview is duplicated after reset app and returning to Inbox

[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.0-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-2922/folder/13176872/41237334/1121354962
Email or phone of affected tester (no customers): sjdoijnsodjosjosdd@gmail.com
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:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Open the expense report.
5. Click More > Hold.
6. Enter reason and save it.
7. Go to Account > Troubleshoot > Clear cache and restart > Reset and refresh.
8. Go to Inbox.

Expected Result:

Expense preview will not duplicate after reset app and returning to Inbox.

Actual Result:

Expense preview is duplicated after reset app and returning to Inbox.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7048226_1768318885123.17.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022012326751748819182
• Upwork Job ID: 2012326751748819182
• Last Price Increase: 2026-01-24

Issue Owner

Current Issue Owner: @aimane-chnaif

[melvin-bot]

Triggered auto assignment to @lydiabarclay (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.

[annaweber830]

Proposal

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

After creating an expense, holding it, then using Account → Troubleshoot → Clear cache and restart → Reset and refresh, returning to Inbox can show the same expense preview duplicated in the Left Hand Navigation (LHN) list.

What is the root cause of that problem?

During the “reset and refresh” flow, the app clears most Onyx keys and then rehydrates state via OpenApp. In that brief rehydration window (and/or due to preserved/merged state like drafts), we can end up with multiple report objects effectively representing the same reportID.
The LHN ordering pipeline ultimately produces an array of orderedReportIDs. If the same reportID appears more than once, the Inbox/LHN renders duplicate rows.

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

Add a defensive, stable de-duplication step to the LHN ordering output (after the list is fully built and sorted), so orderedReportIDs contains unique report IDs only while preserving the first occurrence’s position.
Add a unit test to ensure the ordering function never returns duplicate reportIDs even if the input contains two report entries with the same underlying reportID.

App/src/libs/SidebarUtils.ts

Line 547 in 3bf7f14

return result;

return Array.from(new Set(result));

What alternative solutions did you explore? (Optional)

[abbasifaizan70]

🚨 Edited by proposal-police: This proposal was edited at 2026-01-17 18:26:47 UTC.

Proposal

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

Expense preview is duplicated after resetting the app and returning to Inbox.

What is the root cause of that problem?

The issue occurs in the putOnHold flow in App/src/libs/actions/IOU/Hold.ts. When a transaction thread doesn't exist, the function creates it optimistically and also links the parent IOU action by setting childReportID optimistically:

App/src/libs/actions/IOU/Hold.ts

Lines 188 to 194 in 75c85ae

	if (iouAction?.reportActionID) {
	// We link the IOU action to the new transaction thread by setting childReportID optimistically
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${transactionThreadReport.parentReportID}`,
	value: {[iouAction?.reportActionID]: {childReportID: reportID, childType: CONST.REPORT.TYPE.CHAT}},
	});

The hold action and the hold comment are also created optimistically with pendingAction: ADD. However, on success the flow only clears the transaction’s pendingAction and (when creating a new thread) the thread’s CREATED action pendingAction. It does not clear:

• pendingAction for the hold and hold comment actions in the thread
• pendingAction for the parent IOU action that was linked via childReportID
• pendingFields.createChat on the newly created transaction thread

When cache is cleared and OpenApp is called:

1. The optimistic IOU action with childReportID is merged with server data
2. The server may return the same IOU action but with a different state
3. This can cause getCombinedReportActions in OptionsListUtils to include both the parent report's actions and transaction thread actions in different combinations, leading to duplicate expense previews being displayed

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

Add success data to clear all optimistic pending state created by the hold flow:

File: App/src/libs/actions/IOU/Hold.ts

App/src/libs/actions/IOU/Hold.ts

Lines 114 to 123 in 75c85ae

	const successData: Array<
	OnyxUpdate<typeof ONYXKEYS.COLLECTION.TRANSACTION | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	pendingAction: null,
	},
	},

Clear pendingAction on the hold + comment actions after success

successData.push({
    onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
    value: {
        [createdReportAction.reportActionID]: {pendingAction: null},
        [createdReportActionComment.reportActionID]: {pendingAction: null},
    },
});

App/src/libs/actions/IOU/Hold.ts

Lines 196 to 200 in 75c85ae

	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${transactionThreadReport.parentReportID}`,
	value: {[iouAction?.reportActionID]: {childReportID: null, childType: null}},
	});

Clear pendingAction on the parent IOU action

if (!initialReportID) {
    if (iouAction?.reportActionID) {
        successData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${transactionThreadReport.parentReportID}`,
            value: {[iouAction.reportActionID]: {pendingAction: null}},
        });
    }

App/src/libs/actions/IOU/Hold.ts

Line 203 in 75c85ae

successData.push(

Clear pendingFields.createChat on the new thread report

    
    successData.push({
        onyxMethod: Onyx.METHOD.MERGE,
        key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
        value: {
            pendingFields: {createChat: null},
        },
    });
}

This ensures that after the hold operation completes successfully, all optimistic pending states are properly cleared, preventing duplicate previews from appearing when the app is reset and data is re-fetched from the server.

Demo

Screen.Recording.2026-01-17.at.11.22.10.PM.mov

[bernhardoj]

Let's hold this for #79356

[melvin-bot]

@lydiabarclay Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022012326751748819182