[$250] [Exploratory] 26W16 - Web - Split - Not here page appear after submit one split and remove the other split

[unzig21]

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.60-14
Reproducible in staging?: Yes
Reproducible in production?: Yes
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-20165/folder/13176791/41237173/1343291991
Email or phone of affected tester (no customers): leungbratt6+1804@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11/Chrome
App Component: Chat Report View

Action Performed:

Precondition: Create a manual expense before in Workspace

1. Split the expense previously created in the workspace chat into 2 child splits
2. Open the split expense
3. Click on "More"
4. Select one of the splits and move it to another report (Report 2)
5. Submit the Report 2
6. Open the other split expense in Report 1
7. Click on More > Edit Split
8. Click on "Remove split"
9. Save the split

Expected Result:

Verify the expense has reverted to a regular expense

Actual Result:

Not here page appears

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7132242_1776439572971.split_not_here.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054388487345779952
• Upwork Job ID: 2054388487345779952
• Last Price Increase: 2026-05-13

[MelvinBot]

Proposal

What is the root cause of that problem?

When a split expense has one child moved to another report and that report is submitted, the "Edit Split → Remove split → Save" flow fails to navigate correctly because the reverse-split logic in updateSplitTransactionsFromSplitExpensesFlow doesn't account for this scenario.

The isReverseSplitOperation flag at line 165-166 requires hasEditableSplitExpensesLeft to be true. When the user removes the non-submitted split (the one still on Report 1), the only remaining split expense is the submitted one (on Report 2), so hasEditableSplitExpensesLeft evaluates to false — because its statusNum >= SUBMITTED (set via initSplitExpenseItemData at line 100).

With isReverseSplitOperation = false, two things break:

1. No deleteTransactionNavigateBackUrl is set (line 1372), so the ReportNotFoundGuard suppression mechanism is not armed.
2. Navigation falls through to dismissModalWithReport({reportID: targetReportID}), which navigates to the expense report that is being optimistically deleted — triggering the "Hmm... it's not here" page via ReportNotFoundGuard.

Even if the user removes the submitted split instead (keeping the non-submitted one, making isReverseSplitOperation = true), the reverse split API call (REVERT_SPLIT_TRANSACTION) must reconcile a child that now lives on a different, submitted report — a case the reverse split was not designed for. This can also produce unexpected navigation or data states.

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

The fix should be in updateSplitTransactionsFromSplitExpensesFlow (and potentially updateSplitTransactions):

1. Broaden the isReverseSplitOperation detection to also handle the case where splitExpenses.length === 1 and the remaining split is on a submitted report (i.e., remove the hasEditableSplitExpensesLeft requirement, or add an alternative condition for this specific "moved + submitted child" scenario).
2. Ensure setDeleteTransactionNavigateBackUrl is called before any optimistic report deletion whenever a reverse split will delete the expense report — regardless of whether the remaining split is editable.
3. Ensure the navigation path at lines 1410-1423 (navigateBackOnDeleteTransaction) is taken when the expense report is being deleted, falling back to the chat report via fallbackReportID.

What alternative solutions did you explore? (Optional)

An alternative would be to prevent the "Remove split" action entirely when one child has been moved to a submitted report (since reverting the split is not cleanly possible in that state). However, this would reduce functionality — the proper fix is to handle the navigation correctly so users land on a valid page after the operation.

Supporting evidence and related issues

Draft initialization: When "Edit Split" is opened, initSplitExpense builds splitExpenses from ALL child transactions (including the moved one), each with statusNum from its report (SplitExpenseItems.ts:100).

Report deletion: The expense report is optimistically deleted at SplitTransactionUpdate.ts:1190-1214 when isLastTransactionInReport is true.

"Not here" trigger: ReportNotFoundGuard.tsx:29-104 shows the not-found page when !deleteTransactionNavigateBackUrl && !isLoading && !reportExists.

Likely related issues:

• Expensify/App#87094 — Broken report page after removing split (has merged fix PR fix: Broken report page and report review after removing split #88075)
• Expensify/App#90309 — iOS infinite loading after deleting one split (regression from fix: Broken report page and report review after removing split #88075 fix)
• Expensify/App#75472 — "Not here" after split and move to personal space (on hold for [Splits in NewDot] [Follow up] Enable Splits for unreported expenses #72125)

---

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]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @sobitneupane (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022054388487345779952

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After splitting an expense into two children, moving one child to a different report, submitting that other report, opening the remaining child on the original report, clicking More → Edit Split → Remove split and saving, the app navigates to a "Not Here" page instead of reverting the expense back to a single regular expense on the original report.

What is the root cause of that problem?

The edit-split save flow for this pathway is updateSplitTransactionsFromSplitExpensesFlow in src/libs/actions/IOU/Split.ts. Before invoking the backend it inspects the pending change to decide whether the operation will empty the expense report. Today that check is gated on isReverseSplitOperation:

App/src/libs/actions/IOU/Split.ts

Lines 2231 to 2240 in 7c6e4e8

	const isReverseSplitOperation =
	splitExpenses.length === 1 && originalChildTransactions.length > 0 && hasEditableSplitExpensesLeft && allChildTransactions.length === originalChildTransactions.length;
	const expenseReportID = params.expenseReport?.reportID;
	const isLastTransactionInReport =
	isReverseSplitOperation && Object.values(params.allTransactionsList ?? {}).filter((itemTransaction) => itemTransaction?.reportID === expenseReportID).length === 1;
	const fallbackReportID = params.expenseReport?.chatReportID ?? params.expenseReport?.parentReportID;
	if (isLastTransactionInReport && fallbackReportID) {
	setDeleteTransactionNavigateBackUrl(ROUTES.REPORT_WITH_ID.getRoute(fallbackReportID));
	}

isReverseSplitOperation additionally requires hasEditableSplitExpensesLeft, which checks that the remaining split's report has a status below SUBMITTED:

App/src/libs/actions/IOU/Split.ts

Lines 1126 to 1129 in 7c6e4e8

	const hasEditableSplitExpensesLeft = splitExpenses.some((expense) => (expense.statusNum ?? 0) < CONST.REPORT.STATUS_NUM.SUBMITTED);
	// Don't revert split if there are orphaned children (reportID '0') - they're still part of the split
	const isReverseSplitOperation =
	splitExpenses.length === 1 && originalChildTransactions.length > 0 && hasEditableSplitExpensesLeft && allChildTransactions.length === originalChildTransactions.length;

In the reported scenario the only remaining split (the one that was moved earlier) now lives on the submitted other report, so hasEditableSplitExpensesLeft is false and the operation falls through the UPDATE_SPLIT_TRANSACTION path instead of the revert path. However the optimistic data still removes the child being deleted on the current expense report — and because the sibling was previously moved out, that child was the only transaction left on the current expense report. The expense report therefore becomes empty optimistically.

Because the guard only protects the reverse-split branch, setDeleteTransactionNavigateBackUrl is never called, and navigation falls through to dismissModalWithReport targeting the now-empty expense report:

App/src/libs/actions/IOU/Split.ts

Lines 2291 to 2296 in 7c6e4e8

	const targetReportID = params.expenseReport?.reportID ?? String(CONST.DEFAULT_NUMBER_ID);
	if (isTracking()) {
	setPendingSubmitFollowUpAction(CONST.TELEMETRY.SUBMIT_FOLLOW_UP_ACTION.DISMISS_MODAL_AND_OPEN_REPORT, targetReportID);
	}
	Navigation.dismissModalWithReport({reportID: targetReportID});

ReportNotFoundGuard then sees !deleteTransactionNavigateBackUrl && !reportExists and renders the "Not Here" page:

App/src/pages/inbox/ReportNotFoundGuard.tsx

Lines 47 to 54 in 7c6e4e8

	const reportID = report?.reportID;
	const isOptimisticDelete = report?.statusNum === CONST.REPORT.STATUS_NUM.CLOSED;
	const isInvalidReportPath = !!routeParams?.reportID && !isValidReportIDFromPath(routeParams.reportID);
	const isLoading = isLoadingApp !== false || isLoadingReportData || (!isOffline && !!isLoadingInitialReportActions);
	const reportExists = !!reportID || isOptimisticDelete || userLeavingStatus;
	// eslint-disable-next-line rulesdir/no-negated-variables
	const shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (isInvalidReportPath || (!isLoading && !reportExists));

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

Broaden the condition in updateSplitTransactionsFromSplitExpensesFlow so the pre-save and post-save branches recognise any operation that will leave the expense report empty, not only the reverse-split shape.

Replace the current isLastTransactionInReport computation with a single predicate that asks: "will the expense report have zero transactions after this update?". That is true in exactly two cases:

1. The existing reverse-split path, which deletes all children.
2. The regular update path, when the expense report currently holds a single transaction and none of the remaining splits live on that report (so the sole remaining child on that report is being removed).

When the predicate is true, behave the same way the reverse-split branch does today: call setDeleteTransactionNavigateBackUrl with the fallback chat/parent report before updateSplitTransactions runs so ReportNotFoundGuard suppresses the "Not Here" page during the transition, and after the update use navigateBackOnDeleteTransaction with that same fallback route instead of dismissModalWithReport so the stale expense-report screen is popped from the stack rather than re-entered.

The mutation itself does not need to change — the fix is scoped to navigation. The new predicate subsumes the existing reverse-split case (when isReverseSplitOperation is true, the conjunction reduces to the current check), so behaviour is preserved for all flows that already worked.

Compare branch:

https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88213-split-notfound-after-remove?expand=1

What alternative solutions did you explore? (Optional)

Disabling the Remove split button on the remaining editable split when all sibling splits live on non-editable reports would sidestep the navigation bug, but it silently blocks a legitimate user intent (ending up with a single expense on the current report) without explanation and would leave the underlying navigation gap for any future caller that reaches the same code path. Handling the empty-expense-report case at the navigation layer keeps the fix small and centralised where the optimistic deletion is produced.

[neerajbachani]

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

⚠️ @neerajbachani Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).