Skip to content

[Due for payment 2026-08-07] Split – “Hmm... it’s not here” displayed when removing a split expense #91917

Closed

Description

@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 OwnerCurrent Issue Owner: @sobitneupane

Activity

  1. applause-bot commented on May 28, 2026

    @applause-bot
    Author

    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

  2. added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on May 28, 2026
  3. melvin-bot commented on May 28, 2026

    @melvin-bot

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

  4. melvin-bot commented on May 28, 2026

    @melvin-bot

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

  5. github-actions commented on May 28, 2026

    @github-actions
    Contributor

    👋 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.
  6. changed the title [-]– Split – “Hmm... it’s not here” displayed when removing a split expense[/-] [+]Split – “Hmm... it’s not here” displayed when removing a split expense[/+] on May 28, 2026
  7. MelvinBot commented on May 28, 2026

    @MelvinBot
    Contributor

    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

    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.

  8. 19 remaining items

  9. mitarachim commented on Jul 29, 2026

    @mitarachim

    Deploy Blocker #97403 was identified to be related to the PR #92055 that attempted to fix this issue.

  10. melvin-bot commented on Jul 30, 2026

    @melvin-bot

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

    If a regression has occurred and you are the assigned CM follow the instructions here.

    If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

  11. jponikarchuk commented on Jul 30, 2026

    @jponikarchuk

    Deploy Blocker #97424 was identified to be related to the PR #92055 that attempted to fix this issue.

  12. melvin-bot commented on Jul 30, 2026

    @melvin-bot

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

    If a regression has occurred and you are the assigned CM follow the instructions here.

    If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

  13. lakchote commented on Jul 30, 2026

    @lakchote
    Contributor
  14. melvin-bot commented on Jul 30, 2026

    @melvin-bot

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

    If a regression has occurred and you are the assigned CM follow the instructions here.

    If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

  15. mitarachim commented on Jul 30, 2026

    @mitarachim

    Deploy Blocker #97436 was identified to be related to the PR #92055 that attempted to fix this issue.

  16. changed the title [-]Split – “Hmm... it’s not here” displayed when removing a split expense[/-] [+][Due for payment 2026-08-07] Split – “Hmm... it’s not here” displayed when removing a split expense[/+] on Jul 31, 2026
  17. melvin-bot commented on Jul 31, 2026

    @melvin-bot

    @sobitneupane / @ZhenjaHorbach

    The solution for this issue has been 🚀 deployed to production 🚀 in version 9.4.46-10 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

    If no regressions arise, payment will be issued on 2026-08-07. 🎊

    The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]

  18. melvin-bot commented on Aug 19, 2026

    @melvin-bot

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

    If a regression has occurred and you are the assigned CM follow the instructions here.

    If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

BugSomething is broken. Auto assigns a BugZero manager.DailyKSv2Engineering

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions