[$250] Expense-Deleted report in offline is shown as empty report with unexpected error message

[mitarachim]

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: V9.3.24-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: #82968
Email or phone of affected tester (no customers): dreamnitethedragon@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redminote 10S Android 13
App Component: Money Requests

Action Performed:

1. Launch app

2. Create workspace and enable all options in workflow ( submission frequency, approval and payment)

3. Go to workspace chat

4. Create 2 distance manual expense

5. Go offline

6. Long press and delete first expense

7. Open the second expense and delete

8. Tap more - delete report

9. Go online

10. Navigate back and open workspace chat

11. Note empty report with unexpected error message is shown

12. Tap add expense dropdown and create a distance manual expense

13. Note in deleted report user allowed to create expense and it shows unexpected error.

14. Close the error

15. Open the expense and note error is shown

Expected Result:

Deleted report in offline must not be shown as empty report with unexpected error message.

Actual Result:

Deleted report in offline is shown as empty report with unexpected error message.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7084211_1771660923916.Screenrecorder-2026-02-21-12-45-32-130.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @situchan

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043664440522530461
• Upwork Job ID: 2043664440522530461
• Last Price Increase: 2026-04-20

[MelvinBot]

Proposal

What is the root cause of that problem?

When expenses are deleted individually and then the report is deleted while offline, three commands are queued: DeleteMoneyRequest(A), DeleteMoneyRequest(B), DeleteAppReport. When the app goes online, the SequentialQueue processes them in order. The server may auto-delete the IOU report when the last transaction is removed via DeleteMoneyRequest(B). Then DeleteAppReport fails (report already gone server-side), and its failureData restores the full report object back into Onyx via Onyx.METHOD.SET — creating a ghost empty report.

The error message comes from DeleteMoneyRequest's failureData applying iou.error.genericDeleteFailureMessage to the report actions.

A key contributing factor: shouldDeleteIOUReport is always false for individual deletes because getReportTransactions counts all transactions including those with pendingAction: DELETE (DeleteMoneyRequest.ts:120). This means neither DeleteMoneyRequest call tells the server to clean up the report — the server does it on its own when the last transaction is removed, then DeleteAppReport fails against an already-deleted resource.

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

Add a checkAndFixConflictingRequest handler to DeleteAppReport that detects when all transactions on the report have already been deleted by preceding DeleteMoneyRequest commands in the queue. If the report would already be empty/deleted server-side, remove the DeleteAppReport request from the queue entirely (since the server already handled cleanup).

Alternatively, update DeleteAppReport's failureData to not blindly restore the report — instead of Onyx.METHOD.SET with the full original report, it should set the report to null when the failure is due to a "not found" response (the report was already cleaned up server-side). This would prevent the ghost report from being recreated in Onyx.

What alternative solutions did you explore? (Optional)

1. Fix shouldDeleteIOUReport calculation — filter out transactions with pendingAction: DELETE in the count so the second DeleteMoneyRequest correctly determines it should delete the IOU report. This would prevent DeleteAppReport from being needed at all, but changes behavior broadly and could have side effects on other flows.

2. Skip DeleteAppReport client-side — when calling deleteAppReport, check if all transactions already have pendingAction: DELETE and skip the API call entirely. Simpler but less robust since it only handles this specific ordering.

Investigation details

Key code locations:

• deleteMoneyRequest optimistic/failure data: App/src/libs/actions/IOU/DeleteMoneyRequest.ts:632-915
• deleteAppReport failure data restores report: App/src/libs/actions/Report/index.ts:5973-5977
• WRITE request updates are queued, not immediate: App/src/libs/actions/OnyxUpdates.ts:35
• SequentialQueue FIFO processing: App/src/libs/Network/SequentialQueue.ts:123-263

Data flow:

1. User creates 2 expenses → IOU report with 2 transactions
2. Goes offline
3. Deletes expense A → DELETE_MONEY_REQUEST queued (shouldDeleteIOUReport=false)
4. Deletes expense B → DELETE_MONEY_REQUEST queued (shouldDeleteIOUReport=false — transaction A still counted)
5. Deletes report → DELETE_APP_REPORT queued, failureData captures current report state
6. Goes online → queue flushes in order
7. Server processes both DeleteMoneyRequest calls successfully, auto-cleans IOU report
8. Server returns error for DeleteAppReport (report gone) → failureData SETs full report back into Onyx
9. Ghost empty report appears with "unexpected error" message

Possibly related: #87065 (restored expense detail preview empty after going back online) and #86710 (Onyx data not synced with server / persisted requests).

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @situchan (External)

[melvin-bot]

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

[mukhrr]

Proposal

What is the root cause of that problem?

Two cooperating bugs produce the ghost report.

Bug 1 — shouldDeleteIOUReport never becomes true for individual offline deletes. prepareToCleanUpMoneyRequest decides whether to mark the IOU report as deleted by counting the remaining transactions on the report. It excludes transactions passed in the transactionIDsPendingDeletion array, but the single-delete callers (cleanUpMoneyRequest / getNavigationUrlOnMoneyRequestDelete) never pass that array. Transactions already marked pendingAction: DELETE by a previous queued delete are still counted, so the flag stays false on the second delete.

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

Lines 114 to 120 in 1f51f18

	let canUserPerformWriteAction = true;
	if (chatReport) {
	canUserPerformWriteAction = !!canUserPerformWriteActionReportUtils(chatReport, isChatReportArchived);
	}
	// If we are deleting the last transaction on a report, then delete the report too
	const shouldDeleteIOUReport = getReportTransactions(iouReportID).filter((trans) => !transactionIDsPendingDeletion?.includes(trans.transactionID)).length === 1;

Because of Bug 1, neither DeleteMoneyRequest call tells the server to also delete the IOU report. When the queue flushes online the server auto-cleans the IOU report after removing the last transaction, and the subsequent DeleteAppReport call hits a report that no longer exists and returns an error.

Bug 2 — deleteAppReport failureData resurrects the deleted report with Onyx.METHOD.SET. On failure it writes the full original report object back into Onyx, re-creating the ghost empty report that the user sees. The sibling failure block also restores reportActionsForReport, which is where the "unexpected error" message on the report actions comes from.

App/src/libs/actions/Report/index.ts

Lines 5966 to 5970 in 1f51f18

	failureData.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: report,
	});

App/src/libs/actions/Report/index.ts

Lines 5943 to 5948 in 1f51f18

	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: reportActionsForReport,
	});

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

1. In prepareToCleanUpMoneyRequest, make shouldDeleteIOUReport exclude transactions that are already marked pendingAction: DELETE, so the second queued offline delete correctly decides to delete the IOU report itself (and the matching report actions). This removes the need for a separate DeleteAppReport round-trip in this flow.
   

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

   Line 120 in 1f51f18

   const shouldDeleteIOUReport = getReportTransactions(iouReportID).filter((trans) => !transactionIDsPendingDeletion?.includes(trans.transactionID)).length === 1;

--- a/src/libs/actions/IOU/DeleteMoneyRequest.ts
+++ b/src/libs/actions/IOU/DeleteMoneyRequest.ts
     // If we are deleting the last transaction on a report, then delete the report too
-    const shouldDeleteIOUReport = getReportTransactions(iouReportID).filter((trans) => !transactionIDsPendingDeletion?.includes(trans.transactionID)).length === 1;
+    const shouldDeleteIOUReport =
+        getReportTransactions(iouReportID).filter(
+            (trans) =>
+                !transactionIDsPendingDeletion?.includes(trans.transactionID) &&
+                trans.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
+        ).length === 1;

2. Add a checkAndFixConflictingRequest resolver for DELETE_APP_REPORT in RequestConflictUtils.ts: if every non-deleted money-request action on the target report is already covered by a preceding DELETE_MONEY_REQUEST in the persisted queue, the report will be gone server-side before DELETE_APP_REPORT runs, so drop it. This prevents the failing round-trip that triggers Bug 2, and the optimistic data already put the report into the correct "deleted" state.
   

   App/src/libs/actions/Report/index.ts

   Lines 5650 to 5715 in 1f51f18

   	function deleteAppReport({
   	report,
   	selfDMReport,
   	currentUserEmailParam,
   	currentUserAccountIDParam,
   	reportTransactions,
   	allTransactionViolations,
   	bankAccountList,
   	hash,
   	}: DeleteAppReportProps) {
   	if (!report?.reportID) {
   	Log.warn('[Report] deleteAppReport called with no reportID');
   	return;
   	}
   	const reportID = report.reportID;
   	// Update search results to mark report as deleted when called from search
   	if (hash) {
   	Onyx.merge(`${ONYXKEYS.COLLECTION.SNAPSHOT}${hash}`, {
   	// @ts-expect-error - will be solved in https://github.com/Expensify/App/issues/73830
   	data: {
   	[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]: {pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE},
   	},
   	});
   	}
   	const optimisticData: Array<
   	OnyxUpdate<
   	| typeof ONYXKEYS.COLLECTION.REPORT
   	| typeof ONYXKEYS.COLLECTION.REPORT_METADATA
   	| typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
   	| typeof ONYXKEYS.COLLECTION.TRANSACTION
   	| typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS
   	| typeof ONYXKEYS.SELF_DM_REPORT_ID
   	>
   	> = [];
   	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_METADATA | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [];
   	const failureData: Array<
   	OnyxUpdate<typeof ONYXKEYS.COLLECTION.TRANSACTION | typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT>
   	> = [];
   	let selfDMReportID = selfDMReport?.reportID;
   	let createdAction: ReportAction;
   	let selfDMParameters: SelfDMParameters = {};
   	if (!selfDMReportID) {
   	const currentTime = DateUtils.getDBTime();
   	const optimisticSelfDMReport = buildOptimisticSelfDMReport(currentTime);
   	selfDMReportID = optimisticSelfDMReport.reportID;
   	createdAction = buildOptimisticCreatedReportAction(currentUserEmailParam ?? '', currentTime);
   	selfDMParameters = {reportID: optimisticSelfDMReport.reportID, createdReportActionID: createdAction.reportActionID};
   	optimisticData.push(
   	{
   	onyxMethod: Onyx.METHOD.SET,
   	key: `${ONYXKEYS.COLLECTION.REPORT}${selfDMReportID}`,
   	value: {
   	...optimisticSelfDMReport,
   	pendingFields: {
   	createChat: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
   	},
   	},
   	},
   	{
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: ONYXKEYS.SELF_DM_REPORT_ID,
   	value: selfDMReportID,

--- a/src/libs/actions/RequestConflictUtils.ts
+++ b/src/libs/actions/RequestConflictUtils.ts
+function resolveDeleteAppReportConflict(
+    persistedRequests: AnyRequest[],
+    parameters: DeleteAppReportParams,
+): ConflictActionData {
+    const reportID = parameters.reportID;
+    const transactionIDs = Object.keys(JSON.parse(parameters.transactionIDToReportActionAndThreadData ?? '{}'));
+
+    const allTransactionsAlreadyQueuedForDelete = transactionIDs.every((transactionID) =>
+        persistedRequests.some(
+            (request) => request.command === WRITE_COMMANDS.DELETE_MONEY_REQUEST && request.data?.transactionID === transactionID,
+        ),
+    );
+
+    if (allTransactionsAlreadyQueuedForDelete) {
+        // Server will auto-delete the IOU report once the last DeleteMoneyRequest runs,
+        // so DeleteAppReport would fail and resurrect the report via its failureData.
+        return {conflictAction: {type: 'noAction'}};
+    }
+    return {conflictAction: {type: 'push'}};
+}

3. In deleteAppReport failureData, stop blindly restoring the full report object with Onyx.METHOD.SET. The correct recovery is to re-attach the pending-delete marker the user can retry on, not to overwrite whatever state Onyx already holds — which is what creates the ghost report when the underlying report no longer exists. Switch the restore to Onyx.METHOD.MERGE of a pendingFields.preview: null + errors patch so that a genuine failure surfaces the error on the existing record without ever re-creating a deleted one.
   

   App/src/libs/actions/Report/index.ts

   Lines 5966 to 5970 in 1f51f18

   	failureData.push({
   	onyxMethod: Onyx.METHOD.SET,
   	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
   	value: report,
   	});

--- a/src/libs/actions/Report/index.ts
+++ b/src/libs/actions/Report/index.ts
     failureData.push({
-        onyxMethod: Onyx.METHOD.SET,
+        onyxMethod: Onyx.METHOD.MERGE,
         key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
-        value: report,
+        value: {
+            pendingFields: {preview: null},
+            errorFields: {preview: getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericDeleteFailureMessage')},
+        },
     });

4. Register the new resolver so API.write uses it when DELETE_APP_REPORT is enqueued. Wire it through the same mechanism already used for other conflict-resolving WRITE commands.
   

   App/src/libs/actions/Report/index.ts

   Line 6047 in 1f51f18

--- a/src/libs/actions/Report/index.ts
+++ b/src/libs/actions/Report/index.ts
-    API.write(WRITE_COMMANDS.DELETE_APP_REPORT, parameters, {optimisticData, successData, failureData});
+    API.write(WRITE_COMMANDS.DELETE_APP_REPORT, parameters, {
+        optimisticData,
+        successData,
+        failureData,
+        checkAndFixConflictingRequest: (persistedRequests) => resolveDeleteAppReportConflict(persistedRequests, parameters),
+    });

What alternative solutions did you explore? (Optional)

Only fixing Bug 2 (the failureData restore) without fixing Bug 1 would still leave DELETE_APP_REPORT racing with the server's implicit IOU-report deletion and generate unnecessary failed requests. Only fixing Bug 1 without the conflict resolver would keep the queued DELETE_APP_REPORT around and still resurrect the report via its own failureData. The two fixes together remove both the cause (unnecessary request) and the symptom (bad failure recovery).