You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2026-08-07] Split – “Hmm... it’s not here” displayed when removing a split expense #91917
👋 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:
Identify the pull request that introduced this issue and revert it.
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
The user's central pane is still rendering that transaction thread. ReportNotFoundGuard sees reportExists = false and shows "Hmm... it's not here" because:
deleteTransactionNavigateBackUrl is only set when isLastTransactionInReport is true — not applicable when removing 1 of N splits.
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):
Navigate to the expense report before calling updateSplitTransactions (similar to how the selfDM case pops to the selfDM report first).
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.
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.
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
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]
Activity
applause-bot commentedon May 28, 2026
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 commentedon May 28, 2026
Triggered auto assignment to @danieldoglas (
DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.melvin-bot commentedon May 28, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon May 28, 2026
👋 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:
[-]– Split – “Hmm... it’s not here” displayed when removing a split expense[/-][+]Split – “Hmm... it’s not here” displayed when removing a split expense[/+]MelvinBot commentedon May 28, 2026
Proposal
What is the root cause of that problem?
When a split is removed via Edit Splits and Save is pressed,
updateSplitTransactionsFromSplitExpensesFlowcallsupdateSplitTransactionssynchronously — this optimistically sets the deleted split's transaction thread reportreportIDtonull(viagetCleanUpTransactionThreadReportOnyxData).The user's central pane is still rendering that transaction thread.
ReportNotFoundGuardseesreportExists = falseand shows "Hmm... it's not here" because:deleteTransactionNavigateBackUrlis only set whenisLastTransactionInReportis true — not applicable when removing 1 of N splits.removeScreenByKeyonly 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
popReportsSplitNavigatorToReportto navigate away before the data update and delayupdateSplitTransactionsuntil 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 reachesdismissModalWithReportat line 1936):updateSplitTransactions(similar to how the selfDM case pops to the selfDM report first).updateSplitTransactionstorequestAnimationFrameso 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
deleteTransactionNavigateBackUrlwhen any split child transaction is deleted (not just whenisLastTransactionInReport), soReportNotFoundGuardcan 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 thisto create a draft PR,@MelvinBot <your feedback>to refine this analysis, or explain why you are rejecting Melvin's proposal.19 remaining items
mitarachim commentedon Jul 29, 2026
Deploy Blocker #97403 was identified to be related to the PR #92055 that attempted to fix this issue.
melvin-bot commentedon Jul 30, 2026
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.
jponikarchuk commentedon Jul 30, 2026
Deploy Blocker #97424 was identified to be related to the PR #92055 that attempted to fix this issue.
melvin-bot commentedon Jul 30, 2026
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.
lakchote commentedon Jul 30, 2026
Original issue is not reproducible by QA anymore, see https://expensify.slack.com/archives/C09V78U42D8/p1785396519081229?thread_ts=1785394378.160169&cid=C09V78U42D8
melvin-bot commentedon Jul 30, 2026
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.
mitarachim commentedon Jul 30, 2026
Deploy Blocker #97436 was identified to be related to the PR #92055 that attempted to fix this issue.
[-]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[/+]melvin-bot commentedon Jul 31, 2026
@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]
melvin-bot commentedon Aug 19, 2026
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.