Split - Error when editing expense to higher amount after removing split from report

[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: 9.3.80-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91104
Email or phone of affected tester (no customers): isjdosdjoijosdjosnj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense with amount 10.00.
4. Open the expense.
5. Click More > Split > Save.
6. Open any split.
7. Click Report > Remove from report.
8. Click Amount.
9. Change the amount to 10.00.
10. Click Amount again.
11. Change the amount to 11.00.

Expected Result:

User can edit the expense to higher amount because the split is reverted (no more split label on the amount title).

Actual Result:

Error shows up when editing expense to higher amount after removing split from report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7161011_1779491924657.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7161011

Issue Owner

Current Issue Owner: @lakchote

[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/2008d033bf1365bffbaa96c733f79924e3286d1499d1cc1f02baf840816ee27d

[melvin-bot]

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

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

PR #91104 introduced useHasMultipleSplitChildren, which counts all child transactions matching originalTransactionID — including orphaned ones (reportID = '0', i.e. removed from report). The old code excluded unreported children from this count.

When you "Remove from report" on a split child, changeTransactionsReport sets the child's reportID to '0' but preserves comment.originalTransactionID and comment.source = 'split'. Because the new hook still counts this orphaned child (via child.isSplitSource being true), hasMultipleSplitChildren remains true. This keeps the split indicator visible and routes amount edits through the SplitExpensePage, where computeSplitSaveErrorMessage rejects any amount exceeding the parent's original $10.

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

Filter out unreported (orphaned) children in selectChildTransactionInfo at useHasMultipleSplitChildren.ts:18. Add a check that t?.reportID !== CONST.REPORT.UNREPORTED_REPORT_ID to the filter condition, so removed-from-report children are no longer counted toward hasMultipleSplitChildren. This restores the pre-PR behavior where removing a split child effectively "unsplits" the remaining transaction from the UI's perspective.

This is the minimal fix that addresses the regression without affecting PR #91104's original goal (allowing re-split after sibling deletion), because the re-split flow uses getChildTransactions with includeOrphaned=true separately.

What alternative solutions did you explore? (Optional)

Clearing split metadata (comment.originalTransactionID, comment.source) in changeTransactionsReport when moving to unreported was considered, but that would affect backend state and could break the re-split flow that PR #91104 was fixing.

Investigation details

Data flow:

1. User creates $10 expense → splits into 2 children ($5 each)
2. "Remove from report" on one child → changeTransactionsReport sets reportID = '0' but preserves split metadata
3. useHasMultipleSplitChildren still counts the orphaned child (via isSplitSource = true) → hasMultipleSplitChildren = true
4. Split indicator stays visible → amount edit routes to SplitExpensePage
5. computeSplitSaveErrorMessage compares child amount ($11) against parent amount ($10) → error 'iou.totalAmountGreaterThanOriginal'

Key code locations:

• useHasMultipleSplitChildren.ts:18 — missing UNREPORTED filter
• useHasMultipleSplitChildren.ts:31 — counts orphaned children via isSplitSource
• Transaction.ts:1090 — preserves split metadata on remove-from-report
• SplitExpenseUtils.ts:90-100 — amount validation that triggers the error

Possibly related: #91105 (unable to split a reverted split transaction after deleting the unreported split transaction) — same area of code affected by PR #91104.

---

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.

[mountiny]

@MelvinBot poease raise a straight revert of the offending #91104