[Due for payment 2026-09-16] Report - "It´s not here" RHP opens after navigating to remaining split via preview offline.

[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.74-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: #97308
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has a workspace.

1. Open the staging.new.expensify.com website.
2. Navigate to workspace chat.
3. Create a manual expense.
4. Open the just created expense.
5. Click on "More" > "Split" > Save splits.
6. Turn off internet connection.
7. Open one of the splits.
8. Click on "More" > "Edit Splits"
9. Open the same split.
10. Remove split > "Save"
11. Return to chat.
12. Click on the remaining split card on report preview.
13. Note that "It´s not here" RHP opens instead of remaining split.

Expected Result:

After removing one split while offline and navigating to the remaining one via expense card on report preview, RHP should show the correct expense information.

Actual Result:

"It´s not here" RHP opens after navigating to remaining split via card on report preview while in offline mode, after removing the other split.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7254621_1788908846055.Not_Here_Split.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Vincenzo Godoy
Bug ID: 7254621

Issue Owner

Current Issue Owner: @huult

[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/19c4c8b1c3ac0f3baded2529513abef872f6a76baf3a86956514de1a84fd584b

[melvin-bot]

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

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

@MonilBhavsar @huult you have been assigned to this deploy blocker because you reviewed the offending PR: #97308

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #97308 - "Navigate to the clicked expense in a multi-expense report preview (v2)" by @wildan-m (High confidence that it caused the regression; Medium confidence on the exact Onyx-level mechanism)
Related Issues: #97149 (same "It's not here" class from v1 of this feature, closed by the revert in #97198), #91042 (feature issue)

Recommendation: REVERT

This is the second land of the same feature (v1 #92546 was reverted in #97198 after five blockers, one of which — #97149 — was the identical "expense card → It's not here while offline" symptom), and v2 is already producing the same class of blocker on a flow its offline guards don't cover. A revert restores the well-defined pre-PR behaviour (a preview card opens the parent report), and the PR is self-contained in the report-preview/navigation files, so it reverts cleanly. If the team prefers to roll forward, the targeted fix is spelled out below.

Assigned: @wildan-m (PR author), @MonilBhavsar and @huult (approving reviewers) from the causing PR only
Labels: No changes. DeployBlockerCash stays (App PR caused it, and the App deploy is blocked). DeployBlocker was not on the issue, so nothing to remove.

📋 Detailed Analysis

Evidence

• Before Navigate to the clicked expense in a multi-expense report preview (v2) #97308, every card in the multi-expense report preview carousel called openReportFromPreview, i.e. it always opened the parent expense report. Navigate to the clicked expense in a multi-expense report preview (v2) #97308 changed each card's onPreviewPressed to openTransactionFromPreview(item), which resolves that transaction's transaction-thread report and navigates the RHP to ROUTES.SEARCH_REPORT for it (index.tsx#L345-L391, index.tsx#L258-L343). A card press can therefore land on a report ID that doesn't resolve — which is exactly what "It's not here" is. That failure mode is not reachable from a card press on production/pre-PR code, which matches "Reproducible in production?: N/A – new feature".
• The PR was merged 2026-09-07 and is in the 9.4.74-0 StagingDeployCash, matching the report date (2026-09-09) and the reported version.
• The PR explicitly enumerates this bug family in its own description ("an expense deleted while offline stays in the carousel but its thread is gone → It's not here", [Due for payment 2026-09-16] Report - Expense deleted offline can still be opened and leads to "It´s not here" RHP. #97149) and guards only the offline delete variant. The offline split-removal variant reported here is not covered.
• No backend change is involved: everything happens against optimistic Onyx data while the device is offline, so no API response is in play.

Verification

Files that the bug flows through, all touched or introduced by #97308:

• src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx — added openTransactionFromPreview, resolveChildReportID and navigateToExpense (+305/-27 in the PR).
• src/hooks/useNavigateToTransactionThread.ts and src/libs/actions/TransactionThreadNavigation.ts — also modified by the PR.

gh pr view 97308 --json files confirms all three paths are in the diff, and git log on the split-expense flow (src/libs/actions/IOU/SplitTransactionUpdate.ts) shows no behavioural change to split removal in this deploy — the split flow is unchanged; only the navigation on card press is new.

Root Cause

Where the card press resolves its destination (index.tsx#L232-L256):

const transactionIOUAction = getIOUActionForReportID(transaction.reportID, transaction.transactionID);
let childReportID = transactionIOUAction?.childReportID ?? transaction.transactionThreadReportID;
if (childReportID) {
    setOptimisticTransactionThread(childReportID, iouReport?.reportID ?? transaction.reportID, transactionIOUAction?.reportActionID, iouReport?.policyID ?? policyID);
}

The resolved childReportID is never checked against Onyx: there is no verification that report_<childReportID> still exists, nor that the parent IOU action it points at is alive. It is handed straight to navigateToExpense → ROUTES.SEARCH_REPORT (index.tsx#L372-L381).

Removing a split while offline rewrites exactly that linkage optimistically. Removing one of two splits is a reverse split: the original transaction is restored, the removed split is marked pendingAction: DELETE and its transaction thread is deleted from Onyx, and the surviving split plus its IOU action are removed outright (SplitTransactionUpdate.ts#L1400-L1444, #L1614-L1690, thread teardown in TrackExpense.ts#L684-L755). Offline, the carousel deliberately keeps pending-delete transactions visible (index.tsx#L92), so cards remain on screen whose thread linkage has just been torn down, and there is no server round-trip to repair it.

The press then dead-ends in one of the two not-found gates: the thread report is gone from Onyx (ReportNotFoundGuard.tsx#L73), or setOptimisticTransactionThread re-creates a stub thread whose parent IOU action is deleted/missing (ReportNotFoundGuard.tsx#L136-L155) → "It's not here".

Two contributing weaknesses in the same code path:

1. The only bail-out is transaction.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE (index.tsx#L365). Split removal does not put every affected card into that state — it also nulls/DELETE-marks IOU actions and deletes threads for transactions that are not themselves flagged pending-delete.
2. getIOUActionForTransactionID returns the first action whose originalMessage.IOUTransactionID matches and does not skip deleted ones (ReportActionsUtils.ts#L2701-L2706). After a split → revert cycle a transaction can have more than one IOU action in the expense report, and picking the stale/deleted one yields a childReportID that points at a thread that no longer exists.

Targeted fix, if you prefer to roll forward instead of reverting (all in MoneyRequestReportPreview/index.tsx):

• In resolveChildReportID (L232-L256): only return a childReportID when report_<childReportID> exists in Onyx and its parent IOU action exists and is not deleted (isDeletedAction); drop the unvalidated ?? transaction.transactionThreadReportID fallback. Return undefined otherwise so the caller's final openReportFromPreview() (L390) handles it.
• In openTransactionFromPreview (L365): use isTransactionPendingDelete(transaction) (already imported by this PR) instead of the raw pendingAction comparison, and also fall back to openReportFromPreview() when the transaction's IOU action is missing or deleted while offline.
• Optionally make getIOUActionForTransactionID prefer a non-deleted match, which fixes this class for every caller.

What remains unverified: I could not execute the app or the Jest suite in this environment, so I could not dump the post-revert Onyx state to confirm which of the two not-found gates fires for the pressed card (missing thread report vs. deleted parent action), or which card in the carousel the tester tapped. Both paths originate from the same unvalidated childReportID resolution added by this PR, so the conclusion and the fix are the same either way, but @wildan-m please confirm against the recording before landing a targeted fix rather than a revert.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern (it is the second "It's not here" deploy blocker from the same feature, after #97149), so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: CONSISTENCY-18 Validate an optimistically-derived report ID before navigating to it
• Condition: When a navigation target's reportID comes from derived/optimistic Onyx data (reportAction.childReportID, transaction.transactionThreadReportID, a freshly built optimistic thread), verify the report exists in Onyx and its parent action is present and not deleted before navigating; otherwise navigate to a destination that is guaranteed to exist (usually the parent report). Offline there is no server round-trip to repair a stale ID, so the user lands on the not-found page.
• Why: A dangling thread ID pushed into the RHP renders FullPageNotFoundView ("It's not here") instead of the expense — see this issue and [Due for payment 2026-09-16] Report - Expense deleted offline can still be opened and leads to "It´s not here" RHP. #97149.
• Search pattern: rg -n "childReportID|transactionThreadReportID" src | rg -n "Navigation.navigate|getRoute\(" — flag any Navigation.navigate(ROUTES.SEARCH_REPORT|REPORT_WITH_ID ...) whose reportID traces back to childReportID ?? … or transactionThreadReportID with no existence/deleted check in between.
• Offending code (❌): MoneyRequestReportPreview/index.tsx#L232-L256 and #L372-L381
• Fix (✅): the targeted fix described above (validate in resolveChildReportID, fall back to openReportFromPreview())

The full rule file, with the ❌/✅ code inline in App's coding-standards format, would go in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.

[MelvinBot]

🤖 Web test steps verification results: ❌ fail

I reproduced this on web. After removing one split while offline, tapping the remaining split's card on the report preview opens the "Hmm... it's not here" not-found RHP instead of the expense details.

Step	Status
A manual expense can be created in the workspace chat Created a $50.00 "Split Test Merchant" / Home Office manual expense in a new workspace's chat via + composer > Create expense > Manual; the expense preview card appeared in chat.	✅
The expense can be split via More > Split and the splits save More > Split opened a split editor pre-populated with two $25.00 entries; Save produced two separate $25.00 expense rows on the expense report, totaling $50.00.	✅
While offline, one split can be removed via More > Edit splits > Remove split > Save Toggled Settings > Account > Troubleshoot > Force offline ("You appear to be offline" banner shown). Opened one $25 split, More > Edit splits, drilled into that split row, tapped Remove split, then Save. The removed split showed with strikethrough and the other split absorbed the full $50.00, while offline.	✅
After returning to the chat and tapping the remaining split card on the report preview, the RHP shows the correct expense details (not a not-found page) Bug reproduced. The report preview showed the removed split struck through ($25.00) and the remaining split ($50.00). Tapping the remaining split's card opened the RHP to "Hmm... it's not here — This chat or expense may have been deleted or you do not have access to it." instead of the Amount/Merchant/Category/Date details.	❌

Root cause and recommendation: see my analysis comment above — the offending PR is #97308, and the recommendation is to revert it (a targeted roll-forward fix is also spelled out there).

---

view run · no recording available

[huult]

@wildan-m Could you take a look at this issue?