[$250] Reports - Export warning modal is shown only after opening the exported report

[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.26-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: #81421
Email or phone of affected tester (no customers): sdjsiodjsnodjsonjsio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Search

Action Performed:

Precondition:

• Workspace is connected to Sage Intacct.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Click Submit and Approve.
5. Go to Reports > Reports.
6. Select the report via checkbox.
7. Click dropdown button > Export > Mark as exported.
8. Select the report via checkbox.
9. Click dropdown button > Export > Mark as exported.
   → Export warning modal is not shown.
10. Open the same report and close it.
11. Select the report via checkbox.
12. Click dropdown button > Export > Mark as exported.

→ Export warning modal is shown only after opening the exported report.

Expected Result:

In Step 9, export warning modal will show when exporting the exported report.

Actual Result:

In Step 9, export warning modal is not shown when exporting the exported report.
In Step 12, export warning modal is shown only after opening the exported report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @bernhardoj

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022026733100071687597
• Upwork Job ID: 2026733100071687597
• Last Price Increase: 2026-02-25

[melvin-bot]

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

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

[melvin-bot]

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #81421 - "Add bulk export to accounting integration" by @huult (High confidence)
Related Issues: #79515 (original feature request)

Recommendation: REVERT

PR #81421 introduced bulk export functionality for accounting integrations but has a critical bug in the optimistic state management. The export warning modal is not shown consistently because the report's isExportedToIntegration flag is not updated optimistically, only when the backend responds. Reverting this PR will remove the bulk export feature but restore proper export warning behavior for single report exports.

Labels: Keeping DeployBlockerCash (App deploy blocked). This is a frontend bug that requires an App PR fix.

📋 Detailed Analysis

Evidence

The bug is reproducible in staging but N/A in production because this is a new feature. The issue states that after marking a report as exported (steps 7-9), attempting to export it again (step 9) does NOT show the warning modal. However, after opening and closing the report (steps 10-11), the warning modal DOES appear on the next export attempt (step 12).

Verification

I examined the changes in PR #81421 and identified the root cause in two key files:

File 1: /home/runner/_work/App/App/src/libs/actions/Search.ts (lines 651-733)
The exportToIntegrationOnSearch function adds optimistic report actions but does not optimistically set report.isExportedToIntegration = true. It only updates:

• Report metadata (loading states)
• Report actions (the export action itself)

File 2: /home/runner/_work/App/App/src/libs/actions/Report/index.ts (lines 5206-5260)
The markAsManuallyExported function has the same issue - it only updates report actions, not the report's export status flag.

File 3: /home/runner/_work/App/App/src/pages/Search/SearchPage.tsx (lines 790-836)
The handleExportAction function checks if a report has already been exported by reading report?.isExportedToIntegration from the allReports collection at line 802. Since this flag is never set optimistically, the check fails until the user opens the report (which triggers a full data refresh from the backend).

Root Cause

When exporting a report via the bulk export feature:

1. The export action is added to report actions optimistically ✓
2. The report metadata is updated with loading states ✓
3. Missing: The report object's isExportedToIntegration flag is not set to true optimistically ✗
4. The backend eventually returns the correct flag value
5. However, the local state remains stale until the report is opened
6. Therefore, the warning modal check fails on subsequent export attempts

The reason opening the report "fixes" the issue is that opening a report triggers a full data fetch from the backend, which includes the updated isExportedToIntegration flag.

This is confirmed by the PR diff showing that exportToIntegrationOnSearch and markAsManuallyExported only push updates to ONYXKEYS.COLLECTION.REPORT_ACTIONS and ONYXKEYS.COLLECTION.REPORT_METADATA, but never to ONYXKEYS.COLLECTION.REPORT with the isExportedToIntegration field.

[MelvinBot]

Proposal

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

When a report is marked as exported (via "Mark as exported") from the Reports list view in Search, attempting to mark the same report as exported again does not show the export warning modal ("already exported" confirmation). The warning only appears after the user opens and closes the report first.

What is the root cause of that problem?

The handleExportAction function in SearchPage.tsx (line 799-804) checks report?.isExportedToIntegration directly from the Onyx COLLECTION.REPORT object to decide whether to show the warning modal:

for (const reportID of selectedReportIDs) {
    const report = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`];
    if (!report?.isExportedToIntegration) {
        continue;
    }
    areAnyReportsExported = true;
    ...
}

However, none of the three export action functions set isExportedToIntegration: true on the report object in their optimistic data. They only add an EXPORTED_TO_INTEGRATION action to COLLECTION.REPORT_ACTIONS:

• markAsManuallyExported in src/libs/actions/Report/index.ts (~line 5206)
• exportToIntegration in src/libs/actions/Report/index.ts (~line 5168)
• exportToIntegrationOnSearch in src/libs/actions/Search.ts (~line 651)

This means after exporting, the local report object in Onyx still has isExportedToIntegration as undefined/false, so the SearchPage check always evaluates to "not exported."

The reason it works after opening the report is that the OpenReport API call fetches fresh data from the server, which updates the report object with isExportedToIntegration: true.

Note: The individual report view (ExportWithDropdownMenu.tsx) doesn't have this bug because it uses ReportUtils.isExported(reportActions, report), which has a fallback that scans COLLECTION.REPORT_ACTIONS for export actions — so it picks up the optimistic report action. The SearchPage bypasses this utility entirely.

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

Add an optimistic Onyx update to set isExportedToIntegration: true on ONYXKEYS.COLLECTION.REPORT in all three export functions. For each function, add to the optimistic data array:

{
    onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
    value: { isExportedToIntegration: true },
}

Files to modify:

• src/libs/actions/Report/index.ts — in both exportToIntegration and markAsManuallyExported
• src/libs/actions/Search.ts — in exportToIntegrationOnSearch

This ensures the report's export status is immediately reflected in Onyx after any export action, so the SearchPage's handleExportAction check sees the correct state without needing to open the report first.

What alternative solutions did you explore? (Optional)

An alternative would be to change SearchPage.tsx's handleExportAction to use ReportUtils.isExported(reportActions, report) instead of directly checking report?.isExportedToIntegration. However, this would require loading reportActions for every selected report in the search view, adding complexity. Setting the optimistic data on the report object is cleaner, more consistent with how other optimistic updates work, and fixes the issue at the source rather than working around it.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.