Reports - Incorrect notification to export reports that are already exported

[izarutskaya]

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.32-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @@rickbalut
Slack conversation (hyperlinked to channel name): #expensify_bugs

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Head to Reports
3. Check To-do list
4. Check reports needs to be exported
5. Confirm reports are already exported

Expected Result:

Not to show notification or under to export reports already exported

Actual Result:

Still showing reports to be exported while it is already exported.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.3666.mp4

Check OP for the details

View all open jobs on GitHub

[melvin-bot]

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

[MobileMage]

Proposal

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

Reports that have already been exported to an accounting integration still appear in the "export reports" to-do widget on the home page, incorrectly prompting users to export them again.

What is the root cause of that problem?

The to-do count for export is computed by the todos.ts derived value config, which calls isExportAction for each report. isExportAction calls isExported(reportActions, report), which checks report.isExportedToIntegration first — but only if that field is not undefined. When both exportToIntegration and markAsManuallyExported fire, their optimistic Onyx updates only write to ONYXKEYS.COLLECTION.REPORT_ACTIONS; they never set report.isExportedToIntegration = true on the report object itself. So report.isExportedToIntegration stays undefined, and the function falls back to scanning report actions. If the server-side EXPORTED_TO_INTEGRATION action comes back with originalMessage.type === 'exportTemplate' (i.e., CONST.EXPORT_TEMPLATE), the isValidExport check evaluates to false and the report is not recognized as exported, leaving it in the to-do list.

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

Lines 5231 to 5266 in 04b333d

	function exportToIntegration(reportID: string, connectionName: ConnectionName) {
	const action = buildOptimisticExportIntegrationAction(connectionName);
	const optimisticReportActionID = action.reportActionID;
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[optimisticReportActionID]: action,
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[optimisticReportActionID]: {
	errors: getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'),
	},
	},
	},
	];
	const params = {
	reportIDList: reportID,
	connectionName,
	type: 'MANUAL',
	optimisticReportActions: JSON.stringify({
	[reportID]: optimisticReportActionID,
	}),
	} satisfies ReportExportParams;
	API.write(WRITE_COMMANDS.REPORT_EXPORT, params, {optimisticData, failureData});

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

Both exportToIntegration and markAsManuallyExported should optimistically set isExportedToIntegration: true on the report in ONYXKEYS.COLLECTION.REPORT and revert it to undefined in the failure data. This way the derived todos computation sees report.isExportedToIntegration === true immediately and skips the fragile action-scanning fallback entirely.

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

Lines 5269 to 5319 in 04b333d

	function markAsManuallyExported(reportID: string, connectionName: ConnectionName) {
	const action = buildOptimisticExportIntegrationAction(connectionName, true);
	const label = CONST.POLICY.CONNECTIONS.NAME_USER_FRIENDLY[connectionName];
	const optimisticReportActionID = action.reportActionID;
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[optimisticReportActionID]: action,
	},
	},
	];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[optimisticReportActionID]: {
	pendingAction: null,
	},
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[optimisticReportActionID]: {
	errors: getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'),
	},
	},
	},
	];
	const params = {
	markedManually: true,
	data: JSON.stringify([
	{
	reportID,
	label,
	optimisticReportActionID,
	},
	]),
	} satisfies MarkAsExportedParams;
	API.write(WRITE_COMMANDS.MARK_AS_EXPORTED, params, {optimisticData, successData, failureData});

 function exportToIntegration(reportID: string, connectionName: ConnectionName) {
     const action = buildOptimisticExportIntegrationAction(connectionName);
     const optimisticReportActionID = action.reportActionID;

     const optimisticData: OnyxUpdate[] = [
         {
             onyxMethod: Onyx.METHOD.MERGE,
             key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
             value: {[optimisticReportActionID]: action},
         },
+        {
+            onyxMethod: Onyx.METHOD.MERGE,
+            key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
+            value: {isExportedToIntegration: true},
+        },
     ];

     const failureData: OnyxUpdate[] = [
         {
             onyxMethod: Onyx.METHOD.MERGE,
             key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
             value: {[optimisticReportActionID]: {errors: getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage')}},
         },
+        {
+            onyxMethod: Onyx.METHOD.MERGE,
+            key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
+            value: {isExportedToIntegration: undefined},
+        },
     ];
     // ...
 }

 function markAsManuallyExported(reportID: string, connectionName: ConnectionName) {
     // ... existing action optimistic/failure data ...
+    optimisticData.push({
+        onyxMethod: Onyx.METHOD.MERGE,
+        key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
+        value: {isExportedToIntegration: true},
+    });
+    failureData.push({
+        onyxMethod: Onyx.METHOD.MERGE,
+        key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
+        value: {isExportedToIntegration: undefined},
+    });
 }

What alternative solutions did you explore? (Optional)

N/A

[MelvinBot]

Proposal

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

Reports that have already been exported to an accounting integration (e.g., QuickBooks, Xero, NetSuite) still appear in the To-do list under the "Export" tab, incorrectly prompting the user to export them again.

What is the root cause of that problem?

The To-do list determines which reports need to be exported by calling isExportAction() (ReportPrimaryActionUtils.ts:229-272). This function calls isExported() (ReportUtils.ts:12380-12426) to check if a report has already been exported. isExported() has two code paths:

1. Fast-path: If report.isExportedToIntegration is defined, return it directly.
2. Fallback: If the field is undefined, scan reportActions for EXPORTINTEGRATION actions and compare timestamps against "reset" actions.

The bug occurs when report.isExportedToIntegration is undefined (e.g., for reports exported before this field was introduced by the backend, or when the backend response doesn't include it). In that case, the fallback kicks in and scans reportActions. However, the To-do derived value computation (todos.ts:58) reads report actions from the REPORT_ACTIONS Onyx collection, which may only have a subset of actions loaded (due to pagination). If the EXPORTINTEGRATION action is in an older, unloaded page, isExported() returns false, and the report incorrectly appears in the export list.

Additionally, at ReportPrimaryActionUtils.ts:254, hasExportError() is called without passing the report object, which means it misses the report.hasExportError fast-path and also relies solely on scanning potentially-incomplete report actions.

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

1. Pass the report object to hasExportError() in isExportAction() at ReportPrimaryActionUtils.ts:254. Change:

   hasExportErrorUtil(reportActions)
   

   to:

   hasExportErrorUtil(reportActions, report)
   

   This ensures the report.hasExportError fast-path is used when available, consistent with how isExported() is called on line 249.

2. Ensure backend reliably sets report.isExportedToIntegration for all exported reports (including those exported via auto-sync and manual export). This is likely a backend/server-side change that would make the frontend fast-path reliable and eliminate dependence on potentially-incomplete report actions.

3. If a backend fix is not immediately feasible, an alternative frontend mitigation: in isExported(), when report.isExportedToIntegration is undefined and the fallback finds no EXPORTINTEGRATION actions but the report actions list is suspiciously small (indicating pagination), treat the result as inconclusive and avoid showing the report in the To-do export list. This is a more cautious approach that avoids false positives.

What alternative solutions did you explore? (Optional)

• Pre-loading all report actions for To-do computation: This would make the fallback reliable but is expensive and impractical for workspaces with many reports.
• Optimistically setting isExportedToIntegration in exportToIntegration() and markAsManuallyExported() actions: Currently these only create an optimistic report action but don't update the report field. Setting it optimistically would help for newly-exported reports but wouldn't fix the issue for historically-exported reports where the field was never set.

Detailed Investigation

Evidence Chain

1. To-do list computation: todos.ts:71 calls isExportAction(report, login, policy, reportActions) for every expense report. If it returns true, the report is added to reportsToExport.

2. isExportAction logic (line 229-272): Checks policy has a connected integration, user is exporter/admin, then:

   • Line 249: isExported(reportActions, report) → if true, return false (hide from list)
   • Line 254: hasExportError(reportActions) → note: report not passed (missing fast-path)
   • Line 255: If auto-sync enabled AND no export error → return false (auto-sync handles it)
   • Line 267: If report is approved/reimbursed/closed → return true (show in export list)

3. isExported function (line 12380-12426): Fast-path checks report.isExportedToIntegration; fallback scans actions for valid EXPORTINTEGRATION entries with timestamps after any reset actions.

4. The gap: report.isExportedToIntegration is optional (Report.ts:240) and set only by the backend. It is never set optimistically by frontend export actions. When undefined, the fallback depends on having the EXPORTINTEGRATION action loaded in Onyx, which is not guaranteed for reports the user hasn't recently opened.

5. Inconsistency: ReportPreviewActionUtils.canExport() (line 165) uses report.isExportedToIntegration ?? false directly without any fallback to action scanning, creating divergent behavior between the export button on report previews and the To-do list.

Relevant Code

• App/src/libs/actions/OnyxDerived/configs/todos.ts:52-74 - To-do list report categorization
• App/src/libs/ReportPrimaryActionUtils.ts:229-272 - isExportAction() function
• App/src/libs/ReportUtils.ts:12380-12426 - isExported() with dual code paths
• App/src/libs/ReportUtils.ts:12428-12444 - hasExportError() with missed fast-path
• App/src/libs/ReportPreviewActionUtils.ts:152-179 - canExport() with inconsistent check
• App/src/types/onyx/Report.ts:240 - isExportedToIntegration field definition

---

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.