[$250] Workspace chat - Unable to split a reverted split transaction after deleting the unreported split transaction

[izarutskaya]

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: 9.3.77-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @dmkt9
Slack conversation (hyperlinked to channel name): #expensify_open_source

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Navigate to a workspace chat.
3. Submit an expense.
4. Split the expense into two split transactions.
5. Unreport one of them.
6. Go to your self-DM and delete the unreported split transaction.
7. Open the remaining transaction in the workspace chat.
8. Note that you are unable to split it again.

Expected Result:

The reverted split transaction can be split normally.

Actual Result:

The reverted split transaction cannot be split.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

2026-05-19.10-53-22.mp4

Recording.3768.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @dmkt9

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056783076149400578
• Upwork Job ID: 2056783076149400578
• Last Price Increase: 2026-05-19

[MelvinBot]

Proposal

What is the root cause of that problem?

When a split transaction child is unreported (its reportID becomes '0') and then deleted from self-DM, the delete goes through deleteTrackExpense, which has zero split awareness. It simply removes the transaction without ever calling the RevertSplitTransaction API.

This leaves the system in an inconsistent state:

1. The original parent transaction remains stranded with reportID: '-2' (SPLIT_REPORT_ID) — effectively hidden.
2. The remaining child still has comment.originalTransactionID and comment.source = 'split' set.
3. When checking if the remaining child can be split, isExpenseSplit returns true because those comment fields persist.
4. Both useSelectedTransactionsActions and useSearchBulkActions explicitly block splitting when isExpenseSplit is true.

The split-aware delete path exists in useDeleteTransactions, which correctly groups split children and calls updateSplitTransactions (triggering revert when only 1 child remains). But the self-DM delete of an unreported child bypasses this entirely.

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

The self-DM delete path (deleteTrackExpense) should detect when the transaction being deleted is a split child (by checking comment.originalTransactionID and comment.source === 'split') and, when it is, route the deletion through the split-aware logic in updateSplitTransactions / useDeleteTransactions so that RevertSplitTransaction is properly invoked. This would restore the original parent transaction (moving it from reportID: '-2' back to its original report) and clear split metadata on the remaining child.

What alternative solutions did you explore?

An alternative would be to modify isExpenseSplit to return false when the parent transaction no longer has any comment.splits (i.e., after the child is deleted). However, this would only mask the UI symptom without fixing the underlying data inconsistency — the parent transaction would remain stranded at reportID: '-2' forever. The proper fix is to ensure the revert path is always triggered.

Related issues

• [$250] [Exploratory] 26W16 - Web - Split - Not here page appear after submit one split and remove the other split #88213 — "Not here page after submit one split and remove the other split" — likely the same root cause (deleting a split child without proper revert)
• [$250] iOS - Report - Expense report loads infinitely after deleting one split #90309 — "Expense report loads infinitely after deleting one split" — potentially related split cleanup issue
• [Due for payment 2026-05-20] [$250] Broken report page and report review after removing split #87094 — "Broken report page and report review after removing split" — another split deletion inconsistency

---

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.

[melvin-bot]

Current assignee @dmkt9 is eligible for the External assigner, not assigning anyone new.