[Due for payment 2026-08-25] Expense - New report with failed scan expense changes to not here page

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.55-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: #97084
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a manual expense.
4. Create a scan expense with invalid receipt.
5. Wait for scan to fail.
6. Go offline.
7. Open the report.
8. Click Submit, Approve and Mark as paid.
9. Open the new report containing the scan expense.
10. Go online.

Expected Result:

The new report containing the scan expense will not show not here page after returning online.

Actual Result:

The new report containing the scan expense shows not here page after returning online.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7235961_1787018158547.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7235961

Issue Owner

Current Issue Owner: @brunovjk

[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/973b48e3d03579158e0b1853f757a7b3365cae9e0a147ed4b3549af6eab06c2f

[melvin-bot]

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

[melvin-bot]

@deetergp @brunovjk you have been assigned to this deploy blocker because you reviewed the offending PR: #97084

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #97084 - "Fix/96257 optimistic move scan failed on pay approve" by @yusufdeveloper2903 (High confidence)
Related Issues: #96257 (the issue this PR implemented)

Recommendation: REVERT

This PR optimistically creates a brand-new report for the moved scan-failed expense, then deletes that same report in successData on reconnect (because the backend creates its own report with a different ID). If the user is viewing that optimistic report when they come back online, it is yanked out from under them and they land on the "not here" page. A safe fix requires reconciling the optimistic report ID with the backend's (or redirecting the user), which is non-trivial; reverting cleanly restores the prior, acceptable behavior (expense stays put until reconnect).

Assigned: @yusufdeveloper2903 (PR author), @deetergp and @brunovjk (approving reviewers) from the causing PR
Labels: No changes. This is a frontend bug so DeployBlockerCash stays. No DeployBlocker label was present.

📋 Detailed Analysis

Evidence

• PR Fix/96257 optimistic move scan failed on pay approve #97084 is item Implement infinite sessions #7 in the current StagingDeployCash checklist (Deploy Checklist: New Expensify 2026-08-18 #98810) and merged 2026-08-14, so it is new on staging and not yet in production. This matches the report: reproducible on staging, not on production.
• The PR's explicit purpose is to add an optimistic (client-side) split that moves a scan-failed expense into a newly created report on Pay, mirroring what the backend does. The repro steps (mixed manual + scan-failed expense, go offline, Submit/Approve/Mark as paid, open the new report, go online) exercise exactly this new code path.
• The reported symptom ("new report ... shows not here page after returning online") is the direct consequence of the optimistic report being deleted on API success.

Verification

• Affected file: src/libs/actions/IOU/Hold.ts (getReportFromHoldRequestsOnyxData), reached from src/libs/actions/IOU/PayMoneyRequest.ts via the new shouldMoveScanFailedTransactions branch.
• Confirmed the PR modifies these files: src/libs/actions/IOU/Hold.ts, src/libs/actions/IOU/PayMoneyRequest.ts, src/libs/TransactionUtils/index.ts (plus tests).
• The new success-data block is present in the checked-out staging code: Hold.ts L1014-L1036.

Root Cause

The optimistic move builds a new report optimisticExpenseReport and returns its ID as optimisticHoldReportID (used to navigate the user to the new report). On offline Pay, the scan-failed transaction is placed in this optimistic report, and the user can open it.

When the queued request succeeds online, the added successData sets that optimistic report and its report actions to null:

if (shouldMoveScanFailedTransactions) {
    successData.push(
        { onyxMethod: MERGE, key: `${COLLECTION.REPORT}${optimisticExpenseReport.reportID}`, value: null },
        { onyxMethod: MERGE, key: `${COLLECTION.REPORT_ACTIONS}${optimisticExpenseReport.reportID}`, value: null },
        ...
    );
}

The comment on that block explains why: "The backend creates its own report for the moved scan-failed expenses instead of reusing optimisticHoldReportID, so the optimistic one has to be dropped once the real report arrives." That cleanup is correct for a report nobody is looking at, but there is no handling for the case where the user is currently viewing the optimistic report. Deleting the report the user is on drops them onto the "not here" page, since the backend's replacement report has a different ID and the user is never redirected to it.

Fix direction (if rolling forward instead of reverting): reconcile the optimistic report onto the backend's real report ID, or detect that the user is viewing the soon-to-be-deleted optimistic report and redirect them to the backend report, rather than blindly nulling it in successData.