Split – “Hmm... it’s not here” displayed when removing a split expense

[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.83-3
Reproducible in staging?: Yes
Reproducible in production?: No
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-34310/folder/13176791/41237173/1444111378
Email or phone of affected tester (no customers): applausetester+abd2r2@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: v9.3.83-3
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com.
2. Open a workspace chat and create a manual expense.
3. Split the created expense.
4. Click on one of the split expenses.
5. Click More → Edit splits.
6. Select one of the splits and click Remove split.
7. Click Save.

Expected Result:

The split expense should be removed successfully without displaying the “Hmm... it’s not here” message.

Actual Result:

The message “Hmm... it’s not here” is displayed after removing the split expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7164605_1779911609593.2026-05-27_21-44-40.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @sobitneupane

[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/6ad832758b123dc4956ae8d6ab639d62926916afae59c8c7784b32a0e7b9bb1f

[melvin-bot]

Triggered auto assignment to @danieldoglas (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

When a split is removed via Edit Splits and Save is pressed, updateSplitTransactionsFromSplitExpensesFlow calls updateSplitTransactions synchronously — this optimistically sets the deleted split's transaction thread report reportID to null (via getCleanUpTransactionThreadReportOnyxData).

The user's central pane is still rendering that transaction thread. ReportNotFoundGuard sees reportExists = false and shows "Hmm... it's not here" because:

1. deleteTransactionNavigateBackUrl is only set when isLastTransactionInReport is true — not applicable when removing 1 of N splits.
2. removeScreenByKey only removes the original transaction's thread screen (params.firstIOU?.childReportID), not the deleted split child's thread screen that the user is viewing.

The selfDM case already has protection against this exact issue — lines 1860-1878 use popReportsSplitNavigatorToReport to navigate away before the data update and delay updateSplitTransactions until after the animation. The workspace chat path (the default case starting at line 1881) has no equivalent protection.

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

Apply the same navigate-before-delete pattern used for selfDM splits to workspace chat splits in updateSplitTransactionsFromSplitExpensesFlow. Specifically, for the non-selfDM, non-search, non-last-transaction case (the path that currently reaches dismissModalWithReport at line 1936):

1. Navigate to the expense report before calling updateSplitTransactions (similar to how the selfDM case pops to the selfDM report first).
2. Defer updateSplitTransactions to requestAnimationFrame so the optimistic deletion happens after the navigation animation, preventing the stale thread from being visible.

This mirrors the selfDM fix pattern and avoids the "Not Found" flash by ensuring the deleted thread's screen is no longer visible when its data is removed from Onyx.

What alternative solutions did you explore? (Optional)

An alternative would be to always set deleteTransactionNavigateBackUrl when any split child transaction is deleted (not just when isLastTransactionInReport), so ReportNotFoundGuard can redirect. However, this would still show a brief flash before the redirect, and it conflates a split-edit navigation concern with a general delete-transaction fallback mechanism. The navigate-before-delete approach is cleaner and already proven in the selfDM case.

Possibly related issues

• [$250] [Exploratory] 26W16 - Web - Split - Not here page appear after submit one split and remove the other split #88213 — same symptom (not-here page after submitting one split and removing the other), likely the same root cause

---

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.