[Due for payment 2026-05-28] [$250] IOU - The primary action shows pay button instead of Export

[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.58-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-17851/folder/13176908/73685192/1321448031
Email or phone of affected tester (no customers): applausetester+bm8902@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Web
App Component: Other

Action Performed:

Precondition -
QBO connection is established in the workspace.

1. Go to https://staging.new.expensify.com
2. Create a expense in the workspace
3. Submit an expense
4. Approve this expense
5. Press More > Export > Export to QBO

Expected Result:

primary action should show the Export button instead of Pay button after the export fails

Actual Result:

After clicking the Export to QBO button in More Options, the primary action button changes to Pay. then after the export fails, the primary action in the report does not revert to Export, although the primary action in the expense preview updates correctly to Export.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7126869_1775834434466.bandicam_2026-04-10_18-12-00-556.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042641099612060416
• Upwork Job ID: 2042641099612060416
• Last Price Increase: 2026-04-24

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

isPrimaryPayAction in ReportPrimaryActionUtils.ts:215 calls isExported(reportActions) without passing the report object. This forces the isExported utility to fall back to scanning report actions instead of reading the authoritative report.isExportedToIntegration flag.

When an export fails, report.isExportedToIntegration is correctly reverted to false by the failure data, but the optimistic EXPORTED_TO_INTEGRATION report action persists (only getting errors added to it — it is not nulled out). Because this action still has a valid export label (e.g. "QuickBooks Online"), the action-based fallback returns isExported = true, making didExportFail = false. This causes isPrimaryPayAction to return true, and since PAY has higher priority than EXPORT_TO_ACCOUNTING in getReportPrimaryAction, the Export button is never evaluated.

The expense preview works correctly because ReportPreviewActionUtils.canPay reads report.isExportedToIntegration directly from the report object, bypassing the broken action-based path.

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

Pass report to the isExported call at ReportPrimaryActionUtils.ts:215, changing isExportedUtil(reportActions) to isExportedUtil(reportActions, report) — matching the pattern already used by isExportAction at line 279.

This ensures isPrimaryPayAction uses report.isExportedToIntegration (which is properly reverted on failure) rather than the stale optimistic action.

What alternative solutions did you explore? (Optional)

An alternative is to null out the optimistic EXPORTED_TO_INTEGRATION action on failure in exportToIntegration (the way exportToIntegrationOnSearch in Search.ts already does). However, the missing report parameter is the more direct fix — it aligns isPrimaryPayAction with isExportAction and uses the authoritative data source.

Investigation details

Data flow:

1. User exports → exportToIntegration sets report.isExportedToIntegration = true and creates an EXPORTED_TO_INTEGRATION action with label "QuickBooks Online"
2. Export fails → failure data reverts report.isExportedToIntegration to false, but only adds errors to the action (does not remove it)
3. isPrimaryPayAction at line 215 calls isExported(reportActions) without report → falls back to action scan → finds the failed action with valid label → returns true
4. didExportFail = !true && hasExportError = false → isPrimaryPayAction returns true → Pay button shown
5. isExportAction at line 279 correctly calls isExported(reportActions, report) → reads report.isExportedToIntegration = false → would show Export, but never reached because PAY has higher priority

Key evidence:

• ReportPrimaryActionUtils.ts:215: isExportedUtil(reportActions) — missing report
• ReportPrimaryActionUtils.ts:279: isExportedUtil(reportActions, report) — correct usage
• ReportUtils.ts:12632: isExported prefers report.isExportedToIntegration when report is provided
• ReportPreviewActionUtils.ts:126: expense preview reads report.isExportedToIntegration directly (works correctly)

---

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 - @Krishna2323 (External)

[melvin-bot]

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

[wildan-m]

Proposal

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

After a failed QBO export, the report-level primary action button shows Pay instead of reverting to Export, even though the expense preview correctly shows Export.

What is the root cause of that problem?

In isExportAction in ReportPrimaryActionUtils.ts, the call to hasExportError on this line does not pass the report object. Without report, the function falls back to scanning reportActions for INTEGRATIONS_MESSAGE actions instead of reading the authoritative report.hasExportError property. When the error action is not present in the loaded actions array, the function incorrectly returns false, causing isExportAction to bail out early at the syncEnabled && !hasExportError guard — so the Export action is never shown.

Meanwhile, isPrimaryPayAction in the same file correctly passes report to hasExportError on this line, properly detecting the export failure and blocking the Pay action. The expense preview in ReportPreviewActionUtils.ts also reads report.hasExportError directly. So only the report-level primary action has this inconsistency.

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

Pass the report object to hasExportErrorUtil in isExportAction, matching the pattern already used in isPrimaryPayAction and ensuring the authoritative report.hasExportError property is checked instead of relying on the fallback action scan.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87654-export-primary-action-after-fail?expand=1

[Sado771]

Proposal

1. Problem Analysis
   Problem Statement: (State the issue clearly. E.g., "The app crashes when a user attempts to delete a split expense while offline" or "The UI alignment of the 'Submit' button is inconsistent on Android compared to iOS.")

Root Cause: (Identify why it’s happening based on your investigation of the codebase. E.g., "The logic in IOURequestStepUpgrade.tsx calls Navigation.goBack() before the microtask for navigation is completed, causing a race condition.")

2. Technical Solution
   Front-end (React Native):

I will modify the component [Name of Component] to handle the state change using Onyx.

I will implement a check for isOffline using the Network module to ensure UI consistency during intermittent connectivity.

(If it's a UI issue): I will use styles.js to ensure the layout adheres to the flexbox requirements for both mobile and web platforms.

Logic/State Management:

I will update the onPress handler to ensure Navigation actions are prioritized or wrapped in a microtask to prevent the "open and immediately close" behavior.

I will ensure that any changes are reflected in Onyx keys to maintain a single source of truth across the app.

3. Implementation Plan
   Fork and Branch: Fork Expensify/App and create a branch named fix/issue-87654.

Reproduction: Create a test case (or use an existing one) to reproduce the bug on all platforms (Android, iOS, Web).

Code Changes: Apply the technical fixes described above.

Testing:

iOS/Android: Verify the fix on physical devices or emulators using npm run android and npm run ios.

Web/Desktop: Verify via npm run web.

Submission: Submit a Pull Request with clear screenshots/videos of the fix on all platforms and a summary of the testing performed.

4. Regression Prevention
   I will verify that these changes do not impact the [Related Feature, e.g., Money Request flow] and ensure that existing unit tests pass using npm test.

[HamzaSwitch]

Proposal

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

After a failed QuickBooks Online export, the report-level primary action button incorrectly shows Pay instead of reverting to Export. The expense preview on the same report correctly shows Export, so the inconsistency is limited to the top-level report primary action.

What is the root cause of that problem?

There are two distinct bugs in ReportPrimaryActionUtils.ts. Each existing proposal above identifies one of them but misses the other — and because the two bugs compound in sequence, neither fix alone is sufficient to change the user-visible behavior.

Bug 1 — isPrimaryPayAction (around line 215):

const isExported = isExportedUtil(reportActions);                 // ❌ missing `report`
const hasExportError = hasExportErrorUtil(reportActions, report); // ✓ correct
const didExportFail = !isExported && hasExportError;

Without report, isExportedUtil falls back to scanning reportActions for an EXPORTED_TO_INTEGRATION action. After a failed export, this action persists — the failure data only adds errors to it, it is not nulled out. The action-based scan therefore returns isExported = true, even though report.isExportedToIntegration has been correctly reverted to false. This makes didExportFail = !true && hasExportError = false, so the export failure is silently swallowed, isPrimaryPayAction returns true, and since PAY has higher priority than EXPORT in getReportPrimaryAction, the Pay button is shown.

Bug 2 — isExportAction (around line 284):

const isExported = isExportedUtil(reportActions, report);         // ✓ correct
if (isExported) return false;
const hasExportError = hasExportErrorUtil(reportActions);         // ❌ missing `report`
if (syncEnabled && !hasExportError) return false;                 // false-negative early return

Even once Bug 1 is fixed and control reaches isExportAction, hasExportErrorUtil is called without report and falls back to scanning for INTEGRATIONS_MESSAGE actions. Depending on whether the export failure produced such a message in the loaded actions array, the scan may return false, triggering the syncEnabled && !hasExportError early return and skipping the Export path entirely. The authoritative report.hasExportError flag — which the failure data reliably sets — is never consulted.

The two bugs are symmetric copy-paste inconsistencies: each function correctly passes report to one utility and forgets to pass it to the other. The ReportPreviewActionUtils.canPay path that renders the expense preview reads both flags directly from report, which is why the preview works correctly and only the primary action is affected.

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

Pass report to both utility calls that are currently missing it:

  // In isPrimaryPayAction
- const isExported = isExportedUtil(reportActions);
+ const isExported = isExportedUtil(reportActions, report);

  // In isExportAction
- const hasExportError = hasExportErrorUtil(reportActions);
+ const hasExportError = hasExportErrorUtil(reportActions, report);

Net effect after both fixes: isPrimaryPayAction correctly computes didExportFail = true and returns false → control flows to isExportAction → isExported returns false (report reverted) → hasExportError returns true (report flag set) → the syncEnabled && !hasExportError guard is skipped → the Export button is shown, matching the expense preview.

Both fixes are one line each. The combined diff is two lines.

What alternative solutions did you explore? (Optional)

MelvinBot's proposal fixes Bug 1 only. This is necessary but not sufficient. After Melvin's fix, isPrimaryPayAction correctly returns false, but control then reaches isExportAction, where Bug 2 is still present. If the action-based fallback in hasExportErrorUtil(reportActions) returns false for this failure (which is the documented problem wildan-m describes), the syncEnabled && !hasExportError guard returns false and the Export button is still not shown. The symptom on the user's screen would shift from "wrong button (Pay)" to "no button / wrong button" rather than being fixed.

wildan-m's proposal fixes Bug 2 only. This is also necessary but not sufficient. isPrimaryPayAction will still incorrectly return true because Bug 1 remains, and since PAY has higher priority than EXPORT in getReportPrimaryAction, isExportAction is never called and wildan-m's fix never executes.

Only the combination of both fixes restores the correct user-visible behavior.

A third alternative — nulling out the optimistic EXPORTED_TO_INTEGRATION action on failure in exportToIntegration, matching the pattern already used by exportToIntegrationOnSearch in Search.ts — would fix the root data inconsistency at the source rather than teaching each caller to prefer report flags over the action scan. However, that is a heavier change with broader regression surface (it affects the action log and any UI that reads error state off the action), whereas the 2-line parameter fix restores correctness with minimal blast radius. If a future refactor consolidates this logic, nulling at the source would be the right place — but for this issue, the parameter fix is the minimal correct change.

[melvin-bot]

📣 @HamzaSwitch! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[HamzaSwitch]

Contributor details
Your Expensify account email: hamzaswitch1221@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/xhamzax