[$250] Web - Opened expense closes when refreshing the split modal for the same expnese

[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: v9.4.22-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93268
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: windows 11/ Chrome
App Component: Money Requests

Action Performed:

1. Sign in to staging.new.expensify.com
2. Open an expense → tap the ⋯ menu in the header → tap Split. (If tabs do not appear, the expense is already split — skip this scenario.)
3. Switch once to a tab other than the one it opened on (Amount / Percent / Date)
4. Refresh the page

Expected Result:

The same tab is displayed and the expense detail opened in the background is displayed

Actual Result:

The expense detail opened in the background is closed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7194359_1782742448516.bandicam_2026-06-29_17-04-02-512.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071605378746789997
• Upwork Job ID: 2071605378746789997
• Last Price Increase: 2026-07-06

[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/3caea47763b774fec18c7671cfa17c1fcc62f4b137c2bbe5b081209074085074

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-29 14:51:32 UTC.

Proposal

What is the root cause of that problem?

The split modal (SplitExpensePage) is a Right-Hand-Panel route whose background expense detail is not a sibling in the URL – on a reload it is rebuilt purely from the backTo param of the SPLIT_EXPENSE route. getAdaptedStateFromPath resolves that background in getMatchingFullScreenRoute, which reads route.params.backTo and parses it back into the full-screen route that sits under the modal:

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 85 to 114 in 05d32d5

	function getMatchingFullScreenRoute(route: NavigationPartialRoute) {
	const isDynamicScreen = isDynamicRouteScreen(route.name as Screen);
	// Check for backTo param. One screen with different backTo value may need different screens visible under the overlay.
	// Dynamic screens are skipped here because they never carry their own backTo - they only
	// inherit it from the screen underneath. Letting backTo dictate the full-screen route for
	// a dynamic screen would resolve the wrong page.
	if (isRouteWithBackToParam(route) && !isDynamicScreen) {
	const stateForBackTo = getStateFromPath(route.params.backTo as RoutePath);
	// This may happen if the backTo url is invalid.
	const lastRoute = stateForBackTo?.routes.at(-1);
	if (!stateForBackTo || !lastRoute || lastRoute.name === SCREENS.NOT_FOUND) {
	return undefined;
	}
	const isLastRouteFullScreen = isFullScreenName(lastRoute.name);
	// If the state for back to last route is a full screen route, we can use it
	if (isLastRouteFullScreen) {
	return lastRoute;
	}
	const focusedStateForBackToRoute = findFocusedRouteWithOnyxTabGuard(stateForBackTo);
	if (!focusedStateForBackToRoute) {
	return undefined;
	}
	// If not, get the matching full screen route for the back to state.
	return getMatchingFullScreenRoute(focusedStateForBackToRoute);

If that backTo is missing, getMatchingFullScreenRoute returns undefined, and because the plain SPLIT_EXPENSE screen is in none of the RHP_TO_* maps, the code falls through to the generic right-modal fallback and injects a bare REPORTS_SPLIT_NAVIGATOR (no specific report) instead of the expense you opened:

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 351 to 376 in 05d32d5

	if (focusedRoute) {
	const matchingRootRoute = getMatchingFullScreenRoute(focusedRoute);
	// If there is a matching root route, add it to the state.
	if (matchingRootRoute) {
	return getRoutesWithIndex([matchingRootRoute, ...currentState.routes]);
	}
	}
	const onboardingNavigator = currentState.routes.find((route) => route.name === NAVIGATORS.ONBOARDING_MODAL_NAVIGATOR);
	// The onboarding flow consists of several screens. If we open any of the screens, the previous screens from that flow should be in the state.
	if (onboardingNavigator?.state) {
	const adaptedOnboardingNavigator = {
	...onboardingNavigator,
	state: getOnboardingAdaptedState(onboardingNavigator.state),
	};
	return getRoutesWithIndex([getTabNavigatorState({name: SCREENS.HOME}), adaptedOnboardingNavigator]);
	}
	const isRightModalNavigator = currentState.routes.find((route) => route.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR);
	if (isRightModalNavigator) {
	return getRoutesWithIndex([getTabNavigatorState({name: NAVIGATORS.REPORTS_SPLIT_NAVIGATOR}), ...currentState.routes]);
	}

Now the encoding problem. The route declares backTo as a trailing optional path segment (:backTo?), and the three tabs (amount / percentage / date) are nested path segments after it:

App/src/ROUTES.ts

Lines 1577 to 1589 in 05d32d5

	SPLIT_EXPENSE: {
	// TODO: Remove backTo from route once we have find another way to fix navigation issues with tabs
	route: 'create/split-expense/overview/:reportID/:transactionID/:splitExpenseTransactionID/:backTo?',
	getRoute: (reportID: string | undefined, originalTransactionID: string | undefined, splitExpenseTransactionID?: string, backTo?: string) => {
	if (!reportID || !originalTransactionID) {
	Log.warn(`Invalid ${reportID}(reportID) or ${originalTransactionID}(transactionID) is used to build the SPLIT_EXPENSE route`);
	}
	const splitExpenseTransactionIDPart = splitExpenseTransactionID ? `/${splitExpenseTransactionID}` : '/0';
	return getUrlWithBackToParam(`create/split-expense/overview/${reportID}/${originalTransactionID}${splitExpenseTransactionIDPart}`, backTo);
	},
	},

App/src/libs/Navigation/linkingConfig/config.ts

Lines 1772 to 1786 in 05d32d5

	[SCREENS.MONEY_REQUEST.SPLIT_EXPENSE]: {
	path: ROUTES.SPLIT_EXPENSE.route,
	exact: true,
	screens: {
	[CONST.TAB.SPLIT.AMOUNT]: {
	path: CONST.TAB.SPLIT.AMOUNT,
	},
	[CONST.TAB.SPLIT.PERCENTAGE]: {
	path: CONST.TAB.SPLIT.PERCENTAGE,
	},
	[CONST.TAB.SPLIT.DATE]: {
	path: CONST.TAB.SPLIT.DATE,
	},
	},
	},

…but getRoute actually emits backTo as a query param (?backTo=) via getUrlWithBackToParam, not as the :backTo? path segment:

App/src/ROUTES.ts

Lines 36 to 39 in 05d32d5

	function getUrlWithBackToParam<TUrl extends string>(url: TUrl, backTo?: string, shouldEncodeURIComponent = true): `${TUrl}` {
	const backToParam = backTo ? (`${url.includes('?') ? '&' : '?'}backTo=${shouldEncodeURIComponent ? encodeURIComponent(backTo) : backTo}` as const) : '';
	return `${url}${backToParam}` as `${TUrl}`;
	}

This mismatch is harmless only while the URL has no tab segment. The moment a tab is selected, the persisted URL carries the tab segment (.../overview/r/t/0/percentage), and React Navigation’s getStateFromPath no longer maps the ?backTo= query value onto the route’s params – the optional :backTo? slot is shadowed by the following tab segment and the query value is dropped. I verified this directly against the real linking config:

parse  .../overview/REPORT1/TXN1/0?backTo=%2Fr%2FBGREPORT            → params = {reportID, transactionID, splitExpenseTransactionID, backTo:"/r/BGREPORT"}   ✅ backTo kept
parse  .../overview/REPORT1/TXN1/0/percentage?backTo=%2Fr%2FBGREPORT → params = {reportID, transactionID, splitExpenseTransactionID}                       ❌ backTo dropped
parse  .../overview/REPORT1/TXN1/0/%2Fr%2FBGREPORT/percentage        → params = {reportID, transactionID, splitExpenseTransactionID, backTo:"/r/BGREPORT"}   ✅ backTo kept (path form)

So: select a tab → the URL that gets persisted contains the tab segment → on refresh getStateFromPath discards the query backTo → getMatchingFullScreenRoute can’t resolve the background → the opened expense detail is replaced by an empty REPORTS_SPLIT_NAVIGATOR, i.e. it “closes”. (This only surfaces now because web tab switches were made history-inert – they replaceState the tab-bearing URL instead of pushing – in OnyxTabNavigatorConfig/index.web.ts; the underlying defect is the query-vs-path encoding of backTo.)

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

Emit backTo where the route already declares it – as the :backTo? path segment – instead of as a ?backTo= query param. As the third round-trip line above proves, the path form survives even with the tab segment appended (.../0/<encodedBackTo>/percentage still parses backTo correctly), which is exactly why the route was given a :backTo? segment in the first place (see the existing TODO at ROUTES.ts#L1578).

In ROUTES.SPLIT_EXPENSE.getRoute:

- return getUrlWithBackToParam(`create/split-expense/overview/${reportID}/${originalTransactionID}${splitExpenseTransactionIDPart}`, backTo);
+ const baseRoute = `create/split-expense/overview/${reportID}/${originalTransactionID}${splitExpenseTransactionIDPart}` as const;
+ return (backTo ? `${baseRoute}/${encodeURIComponent(backTo)}` : baseRoute) as Route;

encodeURIComponent(backTo) keeps the whole backTo (including its own ?… query, if any) inside a single path segment, so getStateFromPath consistently attaches it to the SPLIT_EXPENSE route’s params, and getPathFromState re-emits it as the :backTo? segment on every subsequent tab switch — no more dropped param on refresh. This is a single-function change in ROUTES.ts, with no change to the navigation engine and no effect on any other route. Minor changes/improvements (e.g. mirroring the same path-form for SPLIT_EXPENSE_SEARCH for consistency) can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Drop the path config for the three split tabs in config.ts#L1772-L1786 so a tab switch never appends a segment (the active tab is already restored from the SELECTED_TAB Onyx value via initialRouteName, independent of the URL). This works but is riskier: the split-tab routes/paths are also used by getSearchScreenNameForRoute to detect the search context, so removing them touches the search flow. Fixing the backTo encoding is the smaller, root-cause change.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-29 14:56:37 UTC.

Proposal

What is the root cause of that problem?

Opening Split for a normal expense creates the split draft and navigates to the split overview route with Navigation.getActiveRoute() as backTo. When the user starts from an expense detail RHP, that backTo is an RHP URL like /e/<expenseReportID>?backTo=/r/<chatReportID>, not just a fullscreen report URL.

App/src/libs/actions/SplitExpenses.ts

Lines 212 to 218 in bda115b

	Onyx.set(`${ONYXKEYS.COLLECTION.SPLIT_TRANSACTION_DRAFT}${transaction?.transactionID}`, draftTransaction);
	if (isSearchTopmostFullScreenRoute()) {
	Navigation.navigate(ROUTES.SPLIT_EXPENSE_SEARCH.getRoute(reportID, transaction.transactionID, undefined, Navigation.getActiveRoute()));
	} else {
	Navigation.navigate(ROUTES.SPLIT_EXPENSE.getRoute(reportID, transaction.transactionID, undefined, Navigation.getActiveRoute()));
	}

The split route serializes that value into create/split-expense/overview/... as the backTo query parameter.

App/src/ROUTES.ts

Lines 1577 to 1588 in bda115b

	SPLIT_EXPENSE: {
	// TODO: Remove backTo from route once we have find another way to fix navigation issues with tabs
	route: 'create/split-expense/overview/:reportID/:transactionID/:splitExpenseTransactionID/:backTo?',
	getRoute: (reportID: string | undefined, originalTransactionID: string | undefined, splitExpenseTransactionID?: string, backTo?: string) => {
	if (!reportID || !originalTransactionID) {
	Log.warn(`Invalid ${reportID}(reportID) or ${originalTransactionID}(transactionID) is used to build the SPLIT_EXPENSE route`);
	}
	const splitExpenseTransactionIDPart = splitExpenseTransactionID ? `/${splitExpenseTransactionID}` : '/0';
	return getUrlWithBackToParam(`create/split-expense/overview/${reportID}/${originalTransactionID}${splitExpenseTransactionIDPart}`, backTo);
	},

After a web refresh, getAdaptedStateFromPath has to rebuild the stack from the URL. In the no-fullscreen-route branch it prepends only one route returned by getMatchingFullScreenRoute.

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 336 to 357 in bda115b

	// If there is no full screen route in the root, we want to add it.
	if (!fullScreenRoute) {
	const focusedRoute = findFocusedRouteWithOnyxTabGuard(currentState);
	if (focusedRoute?.path && isDynamicRouteScreen(focusedRoute.name as Screen)) {
	currentState = getDynamicRouteAdaptedState(currentState, focusedRoute.path) as PartialState<NavigationState<RootNavigatorParamList>>;
	// getDynamicRouteAdaptedState may have already resolved the full screen route.
	// In that case, skip the default full screen route injection below - the state is already complete.
	const hasFullScreenRoute = currentState.routes.some((route) => isFullScreenName(route.name));
	if (hasFullScreenRoute) {
	return currentState;
	}
	}
	if (focusedRoute) {
	const matchingRootRoute = getMatchingFullScreenRoute(focusedRoute);
	// If there is a matching root route, add it to the state.
	if (matchingRootRoute) {
	return getRoutesWithIndex([matchingRootRoute, ...currentState.routes]);
	}

getMatchingFullScreenRoute uses backTo only to resolve the matching fullscreen route, so a backTo stack that contains an expense detail RHP is flattened to its report/background route. The split tab stays selected, but the expense detail RHP that was underneath the split modal before refresh is dropped.

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 88 to 115 in bda115b

	// Check for backTo param. One screen with different backTo value may need different screens visible under the overlay.
	// Dynamic screens are skipped here because they never carry their own backTo - they only
	// inherit it from the screen underneath. Letting backTo dictate the full-screen route for
	// a dynamic screen would resolve the wrong page.
	if (isRouteWithBackToParam(route) && !isDynamicScreen) {
	const stateForBackTo = getStateFromPath(route.params.backTo as RoutePath);
	// This may happen if the backTo url is invalid.
	const lastRoute = stateForBackTo?.routes.at(-1);
	if (!stateForBackTo || !lastRoute || lastRoute.name === SCREENS.NOT_FOUND) {
	return undefined;
	}
	const isLastRouteFullScreen = isFullScreenName(lastRoute.name);
	// If the state for back to last route is a full screen route, we can use it
	if (isLastRouteFullScreen) {
	return lastRoute;
	}
	const focusedStateForBackToRoute = findFocusedRouteWithOnyxTabGuard(stateForBackTo);
	if (!focusedStateForBackToRoute) {
	return undefined;
	}
	// If not, get the matching full screen route for the back to state.
	return getMatchingFullScreenRoute(focusedStateForBackToRoute);
	}

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

Update the refresh/deep-link adaptation path so split expense modal routes with a valid backTo can restore the full adapted backTo stack, not only the fullscreen route returned by getMatchingFullScreenRoute. When the focused route is SPLIT_EXPENSE or SPLIT_EXPENSE_SEARCH and its backTo resolves to a stack such as report fullscreen plus expense detail RHP, prepend that stack before the current split modal route. Keep the existing single-fullscreen fallback for invalid backTo values or backTo values that resolve to only a fullscreen route.

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 351 to 357 in bda115b

	if (focusedRoute) {
	const matchingRootRoute = getMatchingFullScreenRoute(focusedRoute);
	// If there is a matching root route, add it to the state.
	if (matchingRootRoute) {
	return getRoutesWithIndex([matchingRootRoute, ...currentState.routes]);
	}

Keep this in navigation reconstruction rather than SplitExpensePage, because the page already receives backTo and the tab navigator state; the missing behavior is restoring the intermediate RHP underneath the modal after reload.

App/src/pages/iou/SplitExpensePage.tsx

Lines 90 to 104 in bda115b

	const {reportID, transactionID, splitExpenseTransactionID, backTo} = route.params;
	const {shouldUseNarrowLayout, isInLandscapeMode} = useResponsiveLayout();
	const {showConfirmModal} = useConfirmModal();
	const {isOffline} = useNetwork();
	const {isProduction} = useEnvironment();
	const [errorMessage, setErrorMessage] = React.useState<string>('');
	const {currentSearchResults} = useSearchResultsContext();
	const {currentSearchHash, currentSearchQueryJSON} = useSearchQueryContext();
	const {clearSelectedTransactions} = useSearchSelectionActions();
	const {convertToDisplayString, getCurrencySymbol} = useCurrencyListActions();
	const [selectedTab] = useOnyx(`${ONYXKEYS.COLLECTION.SELECTED_TAB}${CONST.TAB.SPLIT_EXPENSE_TAB_TYPE}`);

App/src/pages/iou/SplitExpensePage.tsx

Lines 580 to 635 in bda115b

	<OnyxTabNavigator
	id={CONST.TAB.SPLIT_EXPENSE_TAB_TYPE}
	defaultSelectedTab={CONST.TAB.SPLIT.AMOUNT}
	tabBar={TabSelector}
	>
	<TopTab.Screen name={CONST.TAB.SPLIT.AMOUNT}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<View style={styles.flex1}>
	<SplitList
	data={options}
	initiallyFocusedOptionKey={initiallyFocusedOptionKey ?? undefined}
	onSelectRow={onSelectRow}
	listFooterContent={listFooterContent}
	mode={CONST.TAB.SPLIT.AMOUNT}
	/>
	{!isInLandscapeMode && footerContent}
	</View>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	<TopTab.Screen name={CONST.TAB.SPLIT.PERCENTAGE}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<View style={styles.flex1}>
	<SplitList
	data={options}
	initiallyFocusedOptionKey={initiallyFocusedOptionKey ?? undefined}
	onSelectRow={onSelectRow}
	listFooterContent={listFooterContent}
	mode={CONST.TAB.SPLIT.PERCENTAGE}
	/>
	{!isInLandscapeMode && footerContent}
	</View>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	<TopTab.Screen name={CONST.TAB.SPLIT.DATE}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<View style={styles.flex1}>
	{!isInLandscapeMode && headerDateContent}
	<SplitList
	data={options}
	initiallyFocusedOptionKey={initiallyFocusedOptionKey ?? undefined}
	onSelectRow={onSelectRow}
	listHeaderContent={isInLandscapeMode ? headerDateContent : undefined}
	listFooterContent={listFooterContent}
	mode={CONST.TAB.SPLIT.DATE}
	/>
	{!isInLandscapeMode && footerContent}
	</View>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	</OnyxTabNavigator>

Test coverage:

• Add a navigation unit test for getAdaptedStateFromPath with a split expense overview URL on a non-default tab and a backTo value pointing to /e/<expenseReportID>?backTo=/r/<chatReportID>. Assert the adapted state contains the report fullscreen route, the expense detail RHP, and then the split expense modal.
• Cover Amount, Percentage, and Date tab URLs with a table test or equivalent shared assertion.
• Manually verify on web that opening Split from an expense detail, switching tabs, and refreshing keeps the selected split tab and the expense detail open behind the split modal.

What alternative solutions did you explore? (Optional)

I considered changing tab-child matching for split expense routes, but the tab-hosting screen is already guarded so focused-route lookup can stop at the parent split expense route. That would not restore an expense-detail RHP that was flattened out of the backTo stack. I also considered pushing the expense detail again from SplitExpensePage, but URL refresh/deep-link reconstruction belongs in the navigation adapter.

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

Web - Opened expense closes when refreshing the split modal for the same expnese

What is the root cause of that problem?

I traced this to the path that handles the issue-specific state:

• src/pages/iou/SplitExpensePage.tsx:573 (translate): subtitle={translate('iou.splitExpenseSubtitle', convertToDisplayString(transactionDetailsAmount, transactionDetails?.currency), draftTransaction?.merchant ?? '')}
• src/pages/iou/SplitExpenseEditPage.tsx:196 (SplitExpenseEditPage): : (splitExpenseDraftTransactionDetails?.merchant ?? '');
• src/pages/iou/SplitExpenseEditPage.tsx:302 (translate): title={translate('iou.splitExpenseEditTitle', convertToDisplayString(currentAmount, splitExpenseDraftTransactionDetails?.currency), merchantToDisplay)}
• The local evidence matches this recurring failure shape: optimistic transaction/report data is written to one Onyx key but the visible list reads another derived key. Here, src/pages/iou/SplitExpensePage.tsx:573 and src/pages/iou/SplitExpenseEditPage.tsx:196 do not agree on the same the issue-specific state value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/iou/SplitExpensePage.tsx:573 to derive the issue-specific state from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/iou/SplitExpenseEditPage.tsx:196; that follows the safer family move to align optimistic/success/failure data with the selector consumed by the screen, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/ReportUtils*.ts for the exact issue flow: Web - Opened expense closes when refreshing the split modal for the same expnese.
2. Cover the counter-case near src/pages/iou/SplitExpensePage.tsx:573 so valid existing the issue-specific state behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep the issue-specific state consistent at the first read/write boundary shown above.

[melvin-bot]

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

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-29 14:55:21 UTC.

Proposal

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

When the split modal is opened over an expense detail, switching to a non-default split tab (Percent / Date) and then refreshing the page closes the expense detail that was open in the background instead of keeping it.

What is the root cause of that problem?

The split overview is an RHP whose background screen (the expense detail) is reconstructed from the backTo value when the navigation state is rebuilt from the URL on refresh.

backTo is appended to the split URL as a query parameter:

https://github.com/Expensify/App/blob/62df01fcac8a/src/ROUTES.ts#L36-L39

The split overview also hosts an OnyxTabNavigator whose tabs (amount / percentage / date) are declared as nested path segments of the split route in the linking config:

https://github.com/Expensify/App/blob/62df01fcac8a/src/libs/Navigation/linkingConfig/config.ts#L1772-L1786

So while you stay on the default tab the URL stays .../overview/<reportID>/<transactionID>/0?backTo=<expenseDetail> and backTo lands on the SPLIT_EXPENSE route. But once you switch to a non-default tab the active tab name is added as a path segment, giving .../overview/<reportID>/<transactionID>/0/percentage?backTo=<expenseDetail>. On refresh, React Navigation attaches the trailing backTo query to the focused leaf — which is now the nested tab route (percentage), not the SPLIT_EXPENSE screen.

When the adapter looks for the screen to place behind the modal it uses findFocusedRouteWithOnyxTabGuard, which deliberately stops at the OnyxTab host and returns the SPLIT_EXPENSE route (not the tab child):

https://github.com/Expensify/App/blob/62df01fcac8a/src/libs/Navigation/helpers/findFocusedRouteWithOnyxTabGuard.ts#L10-L22

…and getMatchingFullScreenRoute reads backTo only from that route's own params:

https://github.com/Expensify/App/blob/62df01fcac8a/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts#L85-L96

Because backTo is sitting on the nested tab route and not on SPLIT_EXPENSE, isRouteWithBackToParam is false, the backTo branch is skipped, no full-screen route is derived, and the expense detail beneath the modal is dropped — so refreshing on a non-default tab closes it. On the default tab backTo is still on SPLIT_EXPENSE, which is why the bug only shows up after switching tabs. This is the same fragility the route's own TODO calls out:

https://github.com/Expensify/App/blob/62df01fcac8a/src/ROUTES.ts#L1699-L1710

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

Resolve backTo from the focused nested tab route when the OnyxTab-hosting screen doesn't carry it itself, so the background is restored on any tab. In getAdaptedStateFromPath, read the effective backTo through a small helper and use it in getMatchingFullScreenRoute:

function getEffectiveBackTo(route: NavigationPartialRoute): string | undefined {
  if (typeof route.params?.backTo === "string") {
    return route.params.backTo;
  }
  // A non-default OnyxTab puts the tab name in the path, so the `backTo` query param
  // binds to the focused tab child instead of this screen — read it from there.
  if (screensWithOnyxTabNavigator.has(route.name) && route.state) {
    const focusedTab = route.state.routes.at(
      route.state.index ?? route.state.routes.length - 1,
    );
    if (typeof focusedTab?.params?.backTo === "string") {
      return focusedTab.params.backTo;
    }
  }
  return undefined;
}

getMatchingFullScreenRoute then branches on getEffectiveBackTo(route) instead of reading route.params.backTo directly, so it finds the expense detail route regardless of which tab is active and rebuilds it beneath the modal.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Unit tests on getAdaptedStateFromPath for the split-expense deep link:

• A URL with a non-default tab segment and a backTo query (.../overview/<r>/<t>/0/percentage?backTo=<expenseDetail>) rebuilds the expense detail as the full-screen route beneath the RHP.
• The same holds for each tab (amount, percentage, date), and the default-tab URL keeps working.
• An invalid/empty backTo still falls back safely (no crash, NOT_FOUND handling unchanged).

What alternative solutions did you explore? (Optional)

Normalize the split route so backTo is always serialized as the :backTo? path segment the route already declares (rather than a query param), so it stays attached to SPLIT_EXPENSE even when a tab segment is present. This addresses the root inconsistency but changes the URL shape app-wide and is riskier than the targeted read-side fix above. A similar idea raised by another contributor is to map the split tab child routes back to the parent split route during adaptation; the effect overlaps, but recovering backTo from the focused tab route keeps the change localized to where the value is actually consumed.

[github-actions]

⚠️ @yusufdeveloper2903 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).