[Due for payment 2026-05-07] Split: “Not here” page displayed when selecting split dates

[mitarachim]

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.61-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-21013/folder/13176791/71461417/1356325968?sort=%2Bidentifier
Email or phone of affected tester (no customers): applausetester+abr323@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Web, IOS
App Component: Money Requests

Action Performed:

1. Go to a workspace
2. Create an expense
3. Click on “More”
4. Select “Split”
5. Click on the “Date” field
6. Select “Split dates” option
7. Choose dates and click Save

Expected Result:

User should not redirected to a “Not here” page after saving split dates.

Actual Result:

User is redirected to a “Not here” page after saving split dates.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7134936_1776779345008.2026-04-21_15-37-16.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[melvin-bot]

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

[MelvinBot]

Proposal

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

When splitting an expense and selecting "Split dates" from the date field, saving the dates redirects the user to a "Not here" page instead of navigating back to the split expense overview.

What is the root cause of that problem?

The navigation failure occurs in SplitExpenseCreateDateRagePage.tsx:57 when Navigation.goBack(backTo) is called after saving dates.

The backTo value is generated by Navigation.getActiveRoute(), which calls getPathFromState on the current navigation state. When the user is on the SplitExpensePage DATE tab, this produces a URL like:

create/split-expense/overview/{reportID}/{transactionID}/{splitTxnID}/date?backTo=...

The goBack → goUp flow calls getStateFromPath(backToRoute) at Navigation.ts:428, but the SPLIT_EXPENSE route definition has a conflicting :backTo? optional path parameter at the same position as the /date tab path:

route: 'create/split-expense/overview/:reportID/:transactionID/:splitExpenseTransactionID/:backTo?'

The TODO comment at ROUTES.ts:1172 acknowledges this issue: "Remove backTo from route once we have find another way to fix navigation issues with tabs".

When getStateFromPath parses the URL, the :backTo? path param and the date tab path create ambiguity, causing parsing to fail or produce incorrect params. This leads goUp to fall into the REPLACE fallback at line 465, which navigates to a screen with wrong/missing params, triggering the FullPageNotFoundView ("Not here" page).

Additionally, SPLIT_EXPENSE_CREATE_DATE_RANGE is missing from all RELATIONS maps — only SPLIT_EXPENSE_SEARCH has a RELATIONS entry. This means getAdaptedStateFromPath cannot determine the correct full-screen route to display underneath the RHP when this screen is loaded.

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

1. Fix handleDatePress to use a stable route reference — Instead of passing the raw Navigation.getActiveRoute() output (which includes the problematic tab path + backTo combo) as the backTo param, construct the backTo URL explicitly without the tab path segment. For example, use ROUTES.SPLIT_EXPENSE.getRoute(reportID, originalTransactionID, splitExpenseTransactionID, backTo) directly, bypassing the ambiguous URL generated by getPathFromState.

2. Add SPLIT_EXPENSE_CREATE_DATE_RANGE to the appropriate RELATIONS map — Add an entry so getAdaptedStateFromPath can correctly determine the full-screen route. Based on where the split expense flow is accessed (from reports or search), it should map to the report screen or home, similar to how other money request screens are mapped.

Supporting evidence

• handleDatePress at SplitExpensePage.tsx:431-432 generates the backTo URL
• updateDate at SplitExpenseCreateDateRagePage.tsx:55-57 calls Navigation.goBack(backTo)
• The route ambiguity at ROUTES.ts:1171-1183 with the acknowledged TODO
• goUp REPLACE fallback at Navigation.ts:448-467
• Missing RELATIONS entry — SPLIT_EXPENSE_SEARCH is the only split screen in SEARCH_TO_RHP.ts:54

What alternative solutions did you explore? (Optional)

An alternative would be to avoid using backTo entirely and instead use Navigation.goBack() without arguments (simple pop). However, this may not correctly restore the navigation state in all cases (e.g., deep linking or when the screen is accessed from search). The explicit route construction approach is more reliable and consistent with how other similar flows handle navigation.

---

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.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: Unable to identify a single high-confidence causing PR — see Detailed Analysis
Related Issues: None identified

Recommendation: NEEDS INVESTIGATION

The bug is staging-only and involves the split dates feature (SplitExpenseCreateDateRagePage). After saving split dates, the user is redirected to a "Not here" page. Code analysis shows the redirect is triggered by the FullPageNotFoundView condition (!isSplitAvailable), but the exact regression causing this in this staging cycle could not be identified with high confidence from code review alone.

Assigned: See candidates below — cannot assign from a single causing PR with high confidence
Labels: Both DeployBlockerCash and DeployBlocker are present. Based on analysis: the fix requires changes to Expensify/App, so DeployBlockerCash should remain. DeployBlocker is unrelated to this issue (it covers backend deploys) — however, since the root cause PR is not identified with high confidence, no labels have been removed.

📋 Detailed Analysis

Evidence

Flow that triggers the bug:

1. Create an expense in a workspace
2. Click "More" → "Split" → SplitExpensePage opens with a draft transaction in Onyx
3. Switch to the "Date" tab, click the "Split dates" field
4. Navigation.navigate(ROUTES.SPLIT_EXPENSE_CREATE_DATE_RANGE.getRoute(reportID, transactionID, Navigation.getActiveRoute())) opens SplitExpenseCreateDateRagePage
5. User selects dates and clicks Save
6. updateDate() calls resetSplitExpensesByDateRange(...) then Navigation.goBack(backTo)
7. User lands on a "Not here" page

The "Not here" page logic in both SplitExpensePage and SplitExpenseCreateDateRagePage:

<FullPageNotFoundView shouldShow={!reportID || isEmptyObject(draftTransaction) || !isSplitAvailable}>

Where isSplitAvailable in SplitExpenseCreateDateRagePage.tsx (line 60):

const isSplitAvailable =
  report &&
  transaction &&
  isSplitAction(
    currentReport,
    [transaction],
    originalTransaction,
    login ?? "",
    currentUserAccountID,
    currentPolicy,
  );

The isSplitAction function in ReportSecondaryActionUtils.ts (lines 107–180) requires several conditions including isPolicyExpenseChatEnabled on the policy and specific report status checks.

Candidate causing PRs investigated:

PR	Files Changed	Relevance	Confidence
#86079	ReportSecondaryActionUtils.ts, ReportUtils.ts	Simplifies isHoldActionForTransaction, modifies canHoldUnholdReportAction logic. Same file as isSplitAction.	Low — isSplitAction itself was not changed
#88212	SplitExpensePage.tsx, SplitExpenseEditPage.tsx	Refactors convertToDisplayString import — pure refactor, no behavioral change	Very Low
#87963	IOU/Split.ts, Navigation.ts	Telemetry refactor in updateSplitTransactionsFromSplitExpensesFlow, not the date range save path	Very Low
#87870	Navigation path helpers	Backward compatibility for migrated routes; changes getMatchingNewRoute regex logic	Low — affects old route redirects, not the split expense paths
#87771	SplitExpensePage.tsx, IOU/Split.ts	TypeScript upgrade; only optional chaining changes with identical behavior	Very Low
#87236	IOU/Split.ts, IOU/index.ts	Changes policyTagList sourcing in updateSplitTransactions	Low — tags unrelated to "Not here"

Verification

Affected files confirmed:

• /home/runner/_work/App/App/src/pages/iou/SplitExpenseCreateDateRagePage.tsx — contains the FullPageNotFoundView triggered on the save path
• /home/runner/_work/App/App/src/libs/ReportSecondaryActionUtils.ts — contains isSplitAction
• /home/runner/_work/App/App/src/libs/actions/IOU/Split.ts — contains resetSplitExpensesByDateRange
• /home/runner/_work/App/App/src/libs/actions/SplitExpenses.ts — contains initSplitExpense (draft initialization)

Unmodified by any staging PR: SplitExpenseCreateDateRagePage.tsx itself, SplitExpenses.ts, isSplitAction function body

Root Cause

The "Not here" page condition has three triggers:

1. !reportID — reportID is a route param, should be stable
2. isEmptyObject(draftTransaction) — resetSplitExpensesByDateRange uses Onyx.merge (not Onyx.set), so it should not clear the draft
3. !isSplitAvailable — most likely trigger; requires report && transaction && isSplitAction(...) all to be truthy

The most probable root cause is that isSplitAvailable becomes false after navigating back to SplitExpensePage. This could happen if:

• currentPolicy is undefined or missing isPolicyExpenseChatEnabled when the page re-renders
• The report from getReportOrDraftReport(reportID) returns undefined
• isSplitAction returns false due to a changed condition related to one of the modified staging PRs

The feature (SplitExpenseCreateDateRagePage) itself appears to be relatively recent and may contain an inherent bug in the isSplitAvailable condition rather than being caused by a specific regression.

Recommended next step: The PR author and reviewers who worked on the split dates feature should test the exact flow on staging and inspect the Onyx state and isSplitAvailable value when the "Not here" page appears. Specifically, verify whether report, transaction, or currentPolicy is undefined or whether isSplitAction returns false and which condition within it fails.