[Due for payment 2026-05-29] [Due for payment 2026-05-28] Expense - 'Export to QuickBooks Online' option only appears after reopening report

[applause-bot]

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.78-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90154
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11, Chrome
App Component: Other

Action Performed:

Precondition:

• QBO integration is connected to the testing account.
• Auto-sync is enabled in the QBO integration.

1. Go to https://staging.new.expensify.com/
2. Create an expense in the workspace
3. Open the expense report
4. Click Submit
5. Click Approve
6. Wait with the expense report open until the export fail
7. Close the expense report and open it again

Expected Result:

The “Export to QuickBooks Online” option should appear immediately after the required action is completed, without needing to close and reopen the report.

Actual Result:

The “Export to QuickBooks Online” option does not appear immediately after the export fails. It only becomes visible after closing the report and opening it again.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7158493_1779256001748.igecrRsZoZ.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7158493

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/bb0a3cc70ae49a77cc87a0b4e41374adce13592a110e220024135ba65c0d5706

[melvin-bot]

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

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

[MelvinBot]

Proposal

What is the root cause of that problem?

PR Expensify/App#90154 changed isExported() and hasExportError() in ReportUtils.ts to short-circuit on report.isExportedToIntegration / report.hasExportError fields when they are defined, skipping the reportActions-based fallback entirely.

When an auto-sync export fails while the report is already open, the server pushes a new INTEGRATIONS_MESSAGE reportAction via Pusher (real-time), but does not push an update to the report object's hasExportError field. Since the report was fetched on open with hasExportError: false, hasExportError() short-circuits at line 12609 and returns false — the newly-pushed reportAction is never checked. This causes isExportAction() to return false (line 276: syncEnabled && !hasExportError), hiding the Export button.

Closing and reopening the report triggers a fresh OpenReport fetch, which returns updated hasExportError: true, and the button appears.

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

In ReportUtils.ts, change hasExportError() so that when report.hasExportError is false, it still falls through to the reportActions-based check. This way, a newly-pushed INTEGRATIONS_MESSAGE error action is picked up in real-time even when the stale report field says no error. The same fix should be applied to isExported() at line 12561 — only short-circuit when the report field is true, and fall through to the reportActions scan when it is false.

Concretely, change both guards from !== undefined to === true:

• if (report?.hasExportError !== undefined) → if (report?.hasExportError === true)
• if (report?.isExportedToIntegration !== undefined) → if (report?.isExportedToIntegration === true)

This preserves the performance benefit of the report-field shortcut when the answer is definitively true, while falling back to the authoritative reportActions scan when the field is false (which may be stale).

What alternative solutions did you explore? (Optional)

1. Fix the backend to include report.hasExportError in the Pusher payload when auto-sync fails. This would be the ideal long-term fix but requires server-side changes and doesn't address the client-side staleness window.
2. Remove the report-field shortcut entirely and always scan reportActions. This would work but loses the optimization that PR Pass report to isExported/hasExportError to fix primary action after failed export #90154 was trying to achieve.

Investigation details

Evidence chain:

1. isExported() short-circuits on report.isExportedToIntegration !== undefined
2. hasExportError() short-circuits on report.hasExportError !== undefined
3. isExportAction() requires hasExportError=true when syncEnabled to show the Export button
4. isPrimaryPayAction() uses didExportFail = !isExported && hasExportError to yield primary slot to Export
5. Only manual export in Report.ts sets isExportedToIntegration optimistically; hasExportError is never set client-side — it comes only from server fetches

Data flow during bug:

• User opens report → OpenReport returns hasExportError: false → stored in Onyx
• Auto-sync fails → Pusher pushes new INTEGRATIONS_MESSAGE reportAction → reportActions update in Onyx
• hasExportError(reportActions, report) called → report.hasExportError is false (defined) → returns false immediately, ignoring the new error action
• Export button stays hidden until report is re-fetched

---

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.