Expense - Not here page opens after refreshing split details RHP

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.90-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: #100032
Email or phone of affected tester (no customers): jsdoijnodsdisojo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Open 1:1 DM with other user.
3. Create a split expense.
4. Open split details page.
5. Refresh the page.

Expected Result:

Split details RHP will open after refreshing the page.

Actual Result:

Not here page opens after refreshing split details RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7263577_1789764550813.1.mp4

View all open jobs on GitHub

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

[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/f2d2381332a6a06a9da27f2aeab5fbf7e0f0097327b0bda4b59911eff9bc8a8b

[melvin-bot]

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

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

@Valforte @linhvovan29546 you have been assigned to this deploy blocker because you reviewed the offending PR: #100032

[melvin-bot]

@TaduJR you have been assigned to this deploy blocker because you authored the offending PR: #100032

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Unconfirmed — no App PR in the 9.4.90-0 checklist changes the split-details refresh path (see analysis). Frontend cause not established; a staging-side/backend difference is the leading remaining explanation.
Causing PR: refactor: Move startSplitBill navigation handling into the UI - by @TaduJR (Low confidence — evidence below argues it is not the cause)
Related Issues: none found

Recommendation: NEEDS INVESTIGATION

Melvin auto-assigned #100032 only because the reporter pasted that PR link into the "caught during regression testing" field, and that PR's code cannot run for the reported repro (a split in an existing 1:1 DM). No other PR on the Deploy Checklist: New Expensify 2026-09-18 changes the behaviour of the split-details deep link, so we need a re-test on production and, if it truly is staging-only, a backend look before reverting anything.

Assigned: no new assignees added — confidence in the candidate PR is too low to attribute the regression to its author/reviewers (existing Melvin auto-assignments left in place).
Labels: No changes. DeployBlockerCash stays (the issue is reported as not reproducible on production and no cause is confirmed). DeployBlocker was never applied, so nothing to remove.

📋 Detailed Analysis

Evidence

Why #100032 is very unlikely to be the cause

1. Its useExpenseSubmission changes are gated behind the scan split branch — iouType === SPLIT && scannedItems.length > 0, where scannedItems only contains transactions that have a receipt file (useExpenseSubmission.ts#L1041-L1057). A manual split in a DM never enters that branch and reaches the unchanged splitBill(...) path below it.
2. Even for a scan split started from an existing 1:1 DM, the PR is a no-op: getOrCreateOptimisticSplitChatReport returns early as soon as an existing chat is found, before any of the new isFirstSplitInBatch / optimisticSplitChatReportID logic is reached (Split.ts#L1437-L1451). The destination report is the DM in both the old and new code, and the new dismissModalAndOpenReportInInboxTab(chatReportID, undefined, false) resolves to the same Navigation.dismissModalWithReport({reportID}) the action used to call itself.
3. Nothing in the PR touches route parsing, the split-details screen, or the report/report-action access checks that render "Not here".

Nothing else in the release touches this path either. Diffing production...staging for every file involved in "refresh /r/:reportID/split/:reportActionID":

File	production → staging
src/pages/inbox/report/withReportAndReportActionOrNotFound.tsx	unchanged
src/libs/Navigation/helpers/getPathFromState.ts	unchanged
src/ROUTES.ts → SPLIT_BILL_DETAILS	unchanged (only a Sage Intacct route was added)
src/libs/Navigation/linkingConfig/config.ts → SPLIT_DETAILS	unchanged
src/libs/Navigation/helpers/getStateFromPath.ts	import-only refactor (linkingConfig.config → config)
src/libs/Navigation/helpers/dynamicRoutesUtils/createDynamicRoute.ts	import-only refactor; getActiveRoute was moved out of Navigation.ts byte-for-byte
src/pages/iou/DynamicSplitBillDetailsPage.tsx	one line: useOnyx(ONYXKEYS.PERSONAL_DETAILS_LIST) → useAllPersonalDetails(), which is literally the same useOnyx call and does not feed any not-found condition

So the client-side logic that decides between rendering the RHP and rendering "Not here" is byte-identical between production and staging.

Verification

Two places can produce the "Not here" screen on this route:

1. withReportAndReportActionOrNotFound.tsx#L98-L112 — renders <NotFoundPage /> when shouldHideReport (report missing from Onyx or canAccessReport false) or when the linked report action resolves to an empty object.
2. DynamicSplitBillDetailsPage.tsx#L158 — <FullPageNotFoundView shouldShow={!reportID || isEmptyObject(reportAction) || isEmptyObject(transaction)}>, i.e. it also shows when the split transaction (transactions_<IOUTransactionID>) is absent.

Route parsing itself checks out: getStateFromPath.ts#L36-L65 peels split/:reportActionID off, re-parses r/:reportID (which focuses SCREENS.REPORT, an allowed entryScreens value for SPLIT_BILL_DETAILS) and merges {reportID, reportActionID} into the screen params. None of that changed this release.

Root Cause

Not established. Because the rendering decision is unchanged, a genuine staging-only reproduction points at the data the screen reads after a cold load rather than at the screen itself — i.e. after refresh one of report, the split reportAction in reportActions_<reportID>, or the split transactions_<IOUTransactionID> (which lives under the split report ID rather than a real report) is not present in Onyx. That would be an issue with what the API returns on app open for a freshly created split, not with any App PR in this checklist.

Next steps:

1. @TaduJR @Valforte @linhvovan29546 — please confirm whether the repro was a Scan split or a manual split, and whether the chat was a pre-existing DM or one created as part of the flow. That single detail decides whether #100032 is even in the code path.
2. Please re-test on production with the exact same steps (create a fresh split, open details, refresh). If it reproduces there, this is not a 9.4.90-0 regression and should be demoted.
3. If it is genuinely staging-only, this looks like a backend/internal issue and a separate internal investigation is needed — the client-side not-found logic did not change in this release.

I have deliberately not removed any labels: no causing PR is confirmed, and the issue is reported as not reproducible on production.