[Due for payment 2026-08-17] [$250] Concierge chat is displayed instead of Filter page when when switch narrow layout

[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.4.25-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: #94785
Email or phone of affected tester (no customers): gocemate+buzz1729@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Search

Action Performed:

1. Login with new account> Select Track on onboarding modal and complete the flow
2. Dismiss the Concierge chat on RHP
3. Go to Spend tab
4. Resize page In narrow layout

Expected Result:

Filter page should open since Concierge chat is dismissed

Actual Result:

Concierge page opens

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7195525_1782832598406.Recording__978.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071996868786605267
• Upwork Job ID: 2071996868786605267
• Last Price Increase: 2026-07-28

Issue Owner

Current Issue Owner: @mallenexpensify

[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/4095588a2e86d719fd1bbde6fc2643f83ffd21b542b49c013725f15c19713089

[MelvinBot]

Proposal

Root Cause

This is a regression from #94785 ("Cleanup of screens related to old search filter routes").

When you resize wide → narrow while the Search Advanced Filters RHP is open on the Spend tab, the layout-change handler useNavigationResetOnLayoutChange.ts:21 runs:

navigation.reset(navigation.getState());

This re-stacks the existing in-memory routes — it does not re-parse the URL or recompute which full-screen route belongs under the RHP via getMatchingFullScreenRoute. If the SearchFullscreenNavigator isn't present beneath the filters RHP in memory, the collapse falls back to getDefaultFullScreenRoute, which returns REPORTS_SPLIT_NAVIGATOR. Its default central screen is the report (ReportsSplitNavigator.tsx:67-79) — for a brand-new account the only report is the Concierge welcome chat. → Concierge opens instead of the Filter page.

PR #94785 changed how the filters RHP is opened: SEARCH_ADVANCED_FILTERS went from a parameterized route to the plain string 'search/filters' (ROUTES.ts), and it's now opened with Navigation.navigate(ROUTES.SEARCH_ADVANCED_FILTERS) instead of .getRoute(). That change is what leaves the Search tab missing as the underlying full screen in the in-memory state.

⚠️ Confidence: Medium. I verified empirically (via jest against the real linking config) that the URL→state resolution is not broken — /search/filters and all /search/filters/:filterKey variants still correctly resolve SearchFullscreenNavigator under the RHP, and the SEARCH_TO_RHP mappings are intact. So the regression is specifically in the in-memory resize path, not deep-linking/refresh. The one fact I couldn't pin without a runtime repro: the exact in-memory root state in wide layout when the filters RHP is open on the Spend tab (i.e. whether SearchFullscreenNavigator or ReportsSplitNavigator sits under the RHP before the resize).

Recommended Fix

Two viable directions:

1. On opening the filters RHP, ensure the Search full-screen navigator is placed underneath it — i.e. that the navigate-time getMatchingFullScreenRoute pre-insertion in linkTo/index.ts:216-265 runs for the new plain 'search/filters' route (it's skipped at L219 when the current top is already an RHP — e.g. the not-yet-dismissed onboarding Concierge RHP).
2. In the resize handler, recompute the underlying full-screen route via getMatchingFullScreenRoute instead of blindly resetting to the current in-memory state.

Direction 1 is the narrower, lower-risk fix and most directly addresses the PR #94785 regression.

Investigation details & verification steps

• Resize trigger: useNavigationResetOnLayoutChange.ts:13-23 — reset(getState()) re-stacks existing routes, no URL re-parse.
• Central-pane decision (path path only): getAdaptedStateFromPath.ts:85-135 (RHP→Search match) and :267-281 (default → Reports/Concierge).
• Filter→Search mapping intact: SEARCH_TO_RHP.ts:6-23 — PR Cleanup of screens related to old search filter routes #94785 only removed the per-filter sub-screens; ADVANCED_FILTERS_RHP / ADVANCED_FILTERS_CONTENT_RHP still map to SCREENS.SEARCH.ROOT.

Decisive next step: Reproduce on staging and dump navigationRef.getRootState() before and after the resize (filters RHP open on Spend tab, fresh account). Confirm whether SearchFullscreenNavigator (vs ReportsSplitNavigator) is the full-screen route directly beneath the RightModalNavigator before the resize. This is purely client-side navigation, so production logs won't help — a browser repro (Playwright) is the right tool.

Alternative explanations considered & ruled out: broken RHP_TO_SEARCH mapping, route collision between search/filters and search/filters/:filterKey, trailing-slash regression — all empirically disproven via round-trip getStateFromPath/getPathFromState tests.

Related issues

No duplicates found. Closest in theme is #90140 (wrong page after navigation) but it has a different trigger/destination — only weakly related.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94996) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[kitvasyl]

Proposal

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

After dismissing Concierge, opening Spend, and resizing from wide to narrow layout, the app shows Concierge instead of Spend’s filter page.

What is the root cause of that problem?

In src/pages/Search/SearchPageNarrow/index.tsx, searchRouterListVisible is initialized to false and is only changed by search-input interactions. There is no state transition for entering narrow layout, so the Search route does not explicitly activate its filter/type menu during the responsive transition and the navigator can continue displaying the previously active Concierge route.

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

Update SearchPageNarrow to detect the transition from wide to narrow layout and set searchRouterListVisible to true when Spend/Search becomes the narrow active page. This makes SearchTypeMenuSwitch the visible content and prevents the stale Concierge screen from winning the transition. Reset the flag when leaving narrow layout so normal wide-layout behavior is preserved, and add a regression test covering dismissal of Concierge followed by switching to Spend and resizing to narrow.

What alternative solutions did you explore? (Optional)

Resetting the entire right-modal navigation stack in RightModalNavigator would also remove Concierge, but it is too broad because resizing should not discard unrelated active RHP screens.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The Track onboarding Concierge side-panel variant opens the side panel with both open and openNarrowScreen set to true via SidePanelActions.openSidePanel(true) (source, source). When the user dismisses that side panel on an extra-large/wide layout, SidePanelContextProvider.closeSidePanel() calls SidePanelActions.closeSidePanel(false), which only clears open and leaves openNarrowScreen as true (source, source). After resizing below the extra-large breakpoint, useSidePanelDisplayStatus() switches its visibility source from sidePanelNVP.open to sidePanelNVP.openNarrowScreen, so the stale true value reopens the Concierge side panel over the Spend/Search filter flow (source).

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

Separate an explicit user close from layout-scoped/automatic closes. For the explicit close path used by SidePanelContextProvider.closeSidePanel(), clear both NVP_SIDE_PANEL.open and NVP_SIDE_PANEL.openNarrowScreen, because dismissing the side panel should mean “closed” across later responsive layout changes, not only closed for the current breakpoint.

Keep the existing narrow-only close behavior for automatic navigation cleanup, such as closeSidePanelOnNarrowScreen(), where the app intentionally closes only the narrow modal while navigating away (source). The minimal implementation would be to add or adjust a SidePanel action that closes the panel everywhere, use it from the user-facing closeSidePanel callback, and leave the current narrow-only action for route-change cleanup.

What alternative solutions did you explore? (Optional)

I also considered handling this only in the Track onboarding caller by opening just open on wide layouts, but that would leave the same stale open/openNarrowScreen mismatch available for any other flow that opens the side panel across breakpoints.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The Side Panel (the "Concierge chat on RHP" shown after Track onboarding) stores its visibility in the NVP_SIDE_PANEL Onyx value as two independent flags, open (used on extra‑large screens) and openNarrowScreen (used on everything else):

• Visibility gate — useSidePanelDisplayStatus reads a different flag per breakpoint:
  

  App/src/hooks/useSidePanelDisplayStatus.tsx

  Line 19 in 0d736c7

  const isSidePanelVisible = isExtraLargeScreenWidth ? sidePanelNVP?.open : sidePanelNVP?.openNarrowScreen;

  const isSidePanelVisible = isExtraLargeScreenWidth ? sidePanelNVP?.open : sidePanelNVP?.openNarrowScreen;

  (isExtraLargeScreenWidth = windowWidth > 1300 and is hard‑coded false on native, so this whole flow is web‑only — matching the Windows/Chrome‑only report:

  App/src/hooks/useResponsiveLayout/index.ts

  Line 36 in 0d736c7

  const isExtraLargeScreenWidth = windowWidth > variables.sidePanelResponsiveWidthBreakpoint;

  and

  App/src/hooks/useResponsiveLayout/index.native.ts

  Line 34 in 0d736c7

  const isExtraLargeScreenWidth = false;

  )

• After completing Track onboarding on a wide screen, navigateAfterOnboarding falls through to the side‑panel variant handler (the small‑screen branch returns early):

  App/src/libs/navigateAfterOnboarding.ts

  Lines 77 to 85 in 0d736c7

  	if (isSmallScreenWidth && variant === CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE) {
  	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID));
  	return;
  	}
  	if (shouldOpenRHPVariant(variantOverride)) {
  	handleRHPVariantNavigation(onboardingPolicyID, variantOverride);
  	return;
  	}

  
  which opens the panel with openSidePanel(true):

  App/src/components/SidePanel/RHPVariantTest/index.ts

  Lines 62 to 78 in 0d736c7

  	const handleRHPVariantNavigation: HandleRHPVariantNavigation = (onboardingPolicyID, variantOverride) => {
  	const variant = variantOverride ?? onboardingRHPVariant;
  	if (variant === CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE) {
  	Navigation.navigate(ROUTES.HOME);
  	SidePanelActions.openSidePanel(true);
  	return;
  	}
  	const isRHPHomePage = variant === CONST.ONBOARDING_RHP_VARIANT.RHP_HOME_PAGE;
  	if (isRHPHomePage) {
  	Navigation.navigate(ROUTES.HOME);
  	} else {
  	Navigation.navigate(ROUTES.WORKSPACE_OVERVIEW.getRoute(onboardingPolicyID));
  	}
  	SidePanelActions.openSidePanel(true);
  	};

• openSidePanel(true) force‑sets both flags, regardless of the current layout:

  App/src/libs/actions/SidePanel.ts

  Lines 9 to 11 in 0d736c7

  	function openSidePanel(shouldOpenOnNarrowScreen: boolean) {
  	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldOpenOnNarrowScreen ? {open: true, openNarrowScreen: true} : {open: true});
  	}

  Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldOpenOnNarrowScreen ? {open: true, openNarrowScreen: true} : {open: true});

  So on an extra‑large screen the NVP becomes {open: true, openNarrowScreen: true} — even though openNarrowScreen is irrelevant to the screen the user is actually on.

• When the user then dismisses the panel on that extra‑large screen, the close handler closes only the flag for the current layout — closeSidePanel(!isExtraLargeScreenWidth) → closeSidePanel(false) → merges {open: false} only:

  App/src/components/SidePanel/SidePanelContextProvider.tsx

  Lines 132 to 144 in 0d736c7

  	const closeSidePanel = (options?: {afterTransition?: () => void}) => {
  	// User shouldn't be able to close side panel if side panel NVP is undefined
  	if (!sidePanelNVP) {
  	return;
  	}
  	onCloseCompleteRef.current = options?.afterTransition;
  	setIsSidePanelTransitionEnded(false);
  	SidePanelActions.closeSidePanel(!isExtraLargeScreenWidth);
  	// Focus the composer after closing the Side Panel
  	focusComposerWithDelay(ReportActionComposeFocusManager.composerRef.current, CONST.SIDE_PANEL_ANIMATED_TRANSITION + CONST.COMPOSER_FOCUS_DELAY)(true);
  	};

  and

  App/src/libs/actions/SidePanel.ts

  Lines 18 to 20 in 0d736c7

  	function closeSidePanel(shouldCloseOnNarrowScreen: boolean) {
  	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldCloseOnNarrowScreen ? {openNarrowScreen: false} : {open: false});
  	}

  
  The NVP is now {open: false, openNarrowScreen: true} — openNarrowScreen is left stale at true.

• Resizing to a narrow layout flips the visibility gate to read openNarrowScreen (still true), so the Side Panel (Concierge) re‑appears over the Spend/Search page. Nothing was navigated; the panel simply re‑shows because of the stale flag.

This is why the normal help‑button flow never hits the bug: it opens with the layout‑aware openSidePanel(!isExtraLargeScreenWidth) (

App/src/components/SidePanel/SidePanelContextProvider.tsx

Lines 146 to 149 in 0d736c7

	const openSidePanel = () => {
	setSessionStartTime(DateUtils.getDBTime());
	SidePanelActions.openSidePanel(!isExtraLargeScreenWidth);
	};

), so on an extra‑large screen openNarrowScreen is never set true and there is nothing stale to resurface. Only the onboarding variant path deviates by hard‑coding openSidePanel(true).

So: Track onboarding openSidePanel(true) sets openNarrowScreen:true on a large screen → dismissing on that large screen clears only open → resize to narrow reads the still‑true openNarrowScreen → Concierge Side Panel re‑opens instead of the Spend/Filter page.

Note: the auto‑linked PR #94785 (cleanup of old search‑filter routes) is unrelated — it has no Side Panel / NVP_SIDE_PANEL interaction. The regression lives in the trackExpensesWithConcierge Side Panel variant flow above.

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

Open the Side Panel for the onboarding variant the same way the rest of the app already does — layout‑aware — so we never write the irrelevant openNarrowScreen flag on a large screen. Reuse the exact pattern already used by the help button at SidePanelContextProvider.tsx#L148 (openSidePanel(!isExtraLargeScreenWidth)); in this non‑component module isExtraLargeScreenWidth is computed the same canonical way already used in Navigation.ts#L202 (Dimensions.get('window').width > variables.sidePanelResponsiveWidthBreakpoint).

In handleRHPVariantNavigation (

App/src/components/SidePanel/RHPVariantTest/index.ts

Lines 62 to 78 in 0d736c7

	const handleRHPVariantNavigation: HandleRHPVariantNavigation = (onboardingPolicyID, variantOverride) => {
	const variant = variantOverride ?? onboardingRHPVariant;
	if (variant === CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE) {
	Navigation.navigate(ROUTES.HOME);
	SidePanelActions.openSidePanel(true);
	return;
	}
	const isRHPHomePage = variant === CONST.ONBOARDING_RHP_VARIANT.RHP_HOME_PAGE;
	if (isRHPHomePage) {
	Navigation.navigate(ROUTES.HOME);
	} else {
	Navigation.navigate(ROUTES.WORKSPACE_OVERVIEW.getRoute(onboardingPolicyID));
	}
	SidePanelActions.openSidePanel(true);
	};

):

+ const isExtraLargeScreenWidth = Dimensions.get('window').width > variables.sidePanelResponsiveWidthBreakpoint;
  ...
- SidePanelActions.openSidePanel(true);
+ SidePanelActions.openSidePanel(!isExtraLargeScreenWidth);

The same one‑line change applies to the other variant branch in the same function (the RHP_HOME_PAGE/workspace‑overview branch at line 77, which also calls openSidePanel(true)). After this, on an extra‑large screen the NVP is {open: true} only, the panel still shows during onboarding (the gate uses open there), and dismissing it leaves nothing stale — resizing to narrow correctly keeps it closed and shows the Spend/Filter page. The medium‑width case is unchanged (it legitimately uses openNarrowScreen). Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Make closeSidePanel clear both flags unconditionally. Rejected: the close is intentionally layout‑scoped — closeSidePanelOnNarrowScreen calls closeSidePanel(true) to close the panel on narrow while deliberately keeping it open on large during in‑app navigation (

App/src/libs/Navigation/Navigation.ts

Lines 198 to 220 in 0d736c7

	/**
	* Close the side panel on narrow layout when navigating to a different screen.
	*/
	function closeSidePanelOnNarrowScreen(route: Route) {
	const isExtraLargeScreenWidth = Dimensions.get('window').width > variables.sidePanelResponsiveWidthBreakpoint;
	if (!sidePanelNVP?.openNarrowScreen || isExtraLargeScreenWidth) {
	return;
	}
	// Split "r/:reportID/attachment/add" by ":reportID" to get the prefix "r/" and suffix "/attachment/add"
	const addAttachmentPrefix = ROUTES.REPORT_ADD_ATTACHMENT.route.split(':reportID').at(0) ?? '';
	const addAttachmentSuffix = ROUTES.REPORT_ADD_ATTACHMENT.route.split(':reportID').at(1) ?? '';
	const attachmentPreviewRoute = ROUTES.REPORT_ATTACHMENTS.route;
	const isAddingAttachment = typeof route === 'string' && route.startsWith(addAttachmentPrefix) && route.includes(addAttachmentSuffix);
	const isPreviewingAttachment = typeof route === 'string' && route.startsWith(attachmentPreviewRoute);
	// If the user is navigating to an attachment route (previewing or adding), keep the side panel open
	// so they still have access to the chat.
	if (isAddingAttachment || isPreviewingAttachment) {
	return;
	}
	SidePanelActions.closeSidePanel(true);

). Forcing close to reset both flags would regress that flow. Fixing the over‑broad open is the smaller, root‑cause change with no impact on the shared close path.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-30 16:58:18 UTC.

Proposal

What is the root cause of that problem?

The Track onboarding variant opens Concierge through the SidePanel state by calling SidePanelActions.openSidePanel(true), which marks the panel open for both desktop (open) and smaller breakpoint (openNarrowScreen) layouts.

App/src/components/SidePanel/RHPVariantTest/index.ts

Lines 62 to 67 in 58045b3

	const handleRHPVariantNavigation: HandleRHPVariantNavigation = (onboardingPolicyID, variantOverride) => {
	const variant = variantOverride ?? onboardingRHPVariant;
	if (variant === CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE) {
	Navigation.navigate(ROUTES.HOME);
	SidePanelActions.openSidePanel(true);
	return;

App/src/libs/actions/SidePanel.ts

Lines 9 to 10 in 58045b3

	function openSidePanel(shouldOpenOnNarrowScreen: boolean) {
	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldOpenOnNarrowScreen ? {open: true, openNarrowScreen: true} : {open: true});

When the user dismisses the side panel on an extra-large layout, SidePanelContextProvider calls SidePanelActions.closeSidePanel(false), and the action only clears open. The narrow-screen flag that was set during onboarding remains true.

App/src/components/SidePanel/SidePanelContextProvider.tsx

Lines 132 to 140 in 58045b3

	const closeSidePanel = (options?: {afterTransition?: () => void}) => {
	// User shouldn't be able to close side panel if side panel NVP is undefined
	if (!sidePanelNVP) {
	return;
	}
	onCloseCompleteRef.current = options?.afterTransition;
	setIsSidePanelTransitionEnded(false);
	SidePanelActions.closeSidePanel(!isExtraLargeScreenWidth);

App/src/libs/actions/SidePanel.ts

Lines 18 to 19 in 58045b3

	function closeSidePanel(shouldCloseOnNarrowScreen: boolean) {
	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldCloseOnNarrowScreen ? {openNarrowScreen: false} : {open: false});

The display hook reads open on extra-large screens, but switches to openNarrowScreen below that breakpoint. After the user resizes to narrow layout, the stale openNarrowScreen value makes the dismissed Concierge panel visible again over Spend/Search.

App/src/hooks/useSidePanelDisplayStatus.tsx

Lines 12 to 29 in 58045b3

	function useSidePanelDisplayStatus() {
	const {isExtraLargeScreenWidth, shouldUseNarrowLayout} = useResponsiveLayout();
	const [sidePanelNVP] = useOnyx(ONYXKEYS.NVP_SIDE_PANEL);
	const [isOnboardingCompleted = false] = useOnyx(ONYXKEYS.NVP_ONBOARDING, {
	selector: hasCompletedGuidedSetupFlowSelector,
	});
	const isAnonymousUser = useIsAnonymousUser();
	const isSidePanelVisible = isExtraLargeScreenWidth ? sidePanelNVP?.open : sidePanelNVP?.openNarrowScreen;
	const isIn2FASetupFlow = useRootNavigationState((state) => {
	const focusedScreen = getDeepestFocusedScreen(state);
	return isTwoFactorSetupScreen(focusedScreen?.name);
	});
	// The Side Panel is hidden when:
	// - NVP is not set or it is false
	// - Onboarding is not completed
	const shouldHideSidePanel = !isSidePanelVisible || !sidePanelNVP || !isOnboardingCompleted;
	const isSidePanelHiddenOrLargeScreen = !isSidePanelVisible || isExtraLargeScreenWidth || !sidePanelNVP;

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

Make SidePanelActions.closeSidePanel() clear both visibility flags for a side-panel dismissal, for example by merging {open: false, openNarrowScreen: false} regardless of the current breakpoint. The existing call sites can stay routed through this action; the boolean argument can either be kept for compatibility or removed in a cleanup.

App/src/libs/actions/SidePanel.ts

Lines 18 to 19 in 58045b3

	function closeSidePanel(shouldCloseOnNarrowScreen: boolean) {
	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldCloseOnNarrowScreen ? {openNarrowScreen: false} : {open: false});

App/src/components/SidePanel/SidePanelContextProvider.tsx

Lines 132 to 140 in 58045b3

	const closeSidePanel = (options?: {afterTransition?: () => void}) => {
	// User shouldn't be able to close side panel if side panel NVP is undefined
	if (!sidePanelNVP) {
	return;
	}
	onCloseCompleteRef.current = options?.afterTransition;
	setIsSidePanelTransitionEnded(false);
	SidePanelActions.closeSidePanel(!isExtraLargeScreenWidth);

This makes a user dismissal the single source of truth across breakpoints, so resizing after Track onboarding cannot resurrect Concierge from the stale inactive-layout flag.

Test coverage:

• Add unit coverage for openSidePanel(true) followed by closeSidePanel(false) and closeSidePanel(true), asserting both open and openNarrowScreen are false after close.
• Add a regression/manual test for Track onboarding: complete Track onboarding, dismiss Concierge, go to Spend/Search, resize below the side-panel breakpoint, and verify Concierge stays closed and the expected Search/filters UI is shown.

What alternative solutions did you explore? (Optional)

I considered only changing the extra-large close branch to also clear openNarrowScreen, but the opposite stale state can happen when closing on a smaller layout and later resizing large. Clearing both flags on dismissal fixes the shared state instead of adding Search-specific cleanup or breakpoint-specific patches.

[abbasifaizan70]

Proposal

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

After completing onboarding with the "Track" flow (which uses the TRACK_EXPENSES_WITH_CONCIERGE variant), the Concierge Side Panel is opened. When the user dismisses it on a large/extra-large screen and then navigates to the Spend tab, resizing the window to a narrow layout causes the Concierge Side Panel to reappear — instead of the Filter page remaining visible.

What is the root cause of that problem?

The NVP_SIDE_PANEL Onyx key tracks two independent flags: open (large screen) and openNarrowScreen (narrow screen). After the TRACK_EXPENSES_WITH_CONCIERGE onboarding variant completes, openSidePanel(true) is called, setting both open: true and openNarrowScreen: true.

The openSidePanel action sets both flags when the narrow-screen argument is true:

App/src/libs/actions/SidePanel.ts

Lines 9 to 11 in a9199d6

	function openSidePanel(shouldOpenOnNarrowScreen: boolean) {
	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldOpenOnNarrowScreen ? {open: true, openNarrowScreen: true} : {open: true});
	}

When the user later dismisses the Side Panel on an extra-large screen, the context's closeSidePanel passes !isExtraLargeScreenWidth = false to the action. Looking at closeSidePanel, only open: false is merged — openNarrowScreen is never touched:

App/src/libs/actions/SidePanel.ts

Lines 17 to 19 in a9199d6

	*/
	function closeSidePanel(shouldCloseOnNarrowScreen: boolean) {
	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldCloseOnNarrowScreen ? {openNarrowScreen: false} : {open: false});

So after the dismissal the NVP is {open: false, openNarrowScreen: true}. When the user resizes to narrow layout, useSidePanelDisplayStatus switches its visibility check from sidePanelNVP?.open to sidePanelNVP?.openNarrowScreen:

App/src/hooks/useSidePanelDisplayStatus.tsx

Lines 19 to 28 in a9199d6

	const isSidePanelVisible = isExtraLargeScreenWidth ? sidePanelNVP?.open : sidePanelNVP?.openNarrowScreen;
	const isIn2FASetupFlow = useRootNavigationState((state) => {
	const focusedScreen = getDeepestFocusedScreen(state);
	return isTwoFactorSetupScreen(focusedScreen?.name);
	});
	// The Side Panel is hidden when:
	// - NVP is not set or it is false
	// - Onboarding is not completed
	const shouldHideSidePanel = !isSidePanelVisible || !sidePanelNVP || !isOnboardingCompleted;

Because openNarrowScreen is still true, isSidePanelVisible becomes true and the Concierge Side Panel reopens — even though the user already dismissed it.

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

closeSidePanel should also clear openNarrowScreen when called from a large screen. A user who explicitly dismisses the Side Panel intends for it to stay closed regardless of any subsequent layout change.

App/src/libs/actions/SidePanel.ts

Lines 17 to 19 in a9199d6

	*/
	function closeSidePanel(shouldCloseOnNarrowScreen: boolean) {
	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldCloseOnNarrowScreen ? {openNarrowScreen: false} : {open: false});

function closeSidePanel(shouldCloseOnNarrowScreen: boolean) {
  Onyx.merge(
    ONYXKEYS.NVP_SIDE_PANEL,
    shouldCloseOnNarrowScreen
      ? { openNarrowScreen: false }
      : { open: false, openNarrowScreen: false },
  );
}

By adding openNarrowScreen: false to the large-screen branch, dismissing on a large/extra-large screen now also clears the narrow-screen flag, so resizing the window to narrow no longer causes the Concierge Side Panel to reappear.

[lorretheboy]

Proposal

What is the root cause of that problem?

The advanced‑filters page is rendered as an RHP only on narrow screens — on wide it is a popover, so it never exists as a route in the nav state on wide:

App/src/components/Search/SearchPageHeader/SearchAdvancedFiltersButton.tsx

Lines 34 to 51 in 2e03359

	if (isSmallScreenWidth) {
	return (
	<PressableWithFeedback
	accessibilityLabel={translate('search.filtersHeader')}
	role={CONST.ROLE.BUTTON}
	style={[styles.searchActionsBar(true)]}
	hoverStyle={styles.buttonHoveredBG}
	sentryLabel={CONST.SENTRY_LABEL.SEARCH.ADVANCED_FILTERS_BUTTON}
	onPress={() => Navigation.navigate(ROUTES.SEARCH_ADVANCED_FILTERS)}
	>
	<Icon
	src={expensifyIcons.Filter}
	fill={theme.icon}
	small
	/>
	</PressableWithFeedback>
	);
	}

When the layout flips to narrow, useNavigationResetOnLayoutChange re‑derives the state via reset(getState()):

App/src/libs/Navigation/AppNavigator/useNavigationResetOnLayoutChange.ts

Lines 16 to 23 in 2e03359

	useEffect(() => {
	if (!navigationRef.isReady()) {
	return;
	}
	navigation.reset(navigation.getState());
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [shouldUseNarrowLayout]);

In getAdaptedState, when the focused route is an open RHP with no full‑screen route under it, the screen that should sit underneath is resolved by looking the RHP route name up in RHP_TO_SEARCH (and the other relations) inside getMatchingFullScreenRoute:

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

Lines 117 to 135 in 2e03359

	const routeNameForLookup = getSearchScreenNameForRoute(route);
	if (RHP_TO_SEARCH[routeNameForLookup]) {
	const paramsFromRoute = getParamsFromRoute(RHP_TO_SEARCH[routeNameForLookup]);
	const copiedParams = paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : {};
	let queryParam: Record<string, string> = {};
	if (route.path) {
	const query = getSearchParamFromPath(route.path, 'q');
	if (query) {
	queryParam = {q: query};
	}
	}
	const searchRoute = {
	name: RHP_TO_SEARCH[routeNameForLookup],
	params: Object.keys({...copiedParams, ...queryParam}).length > 0 ? {...copiedParams, ...queryParam} : undefined,
	};
	const searchState = getRoutesWithIndex([searchRoute]);
	return getTabNavigatorState({name: NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR, state: searchState});
	}

If that lookup returns nothing, the code falls through to a right‑modal fallback that prepends REPORTS_SPLIT_NAVIGATOR — the Inbox/Concierge split — beneath the RHP:

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

Lines 351 to 376 in 2e03359

	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]);
	}

The regression PR (#94785) turned SEARCH_ADVANCED_FILTERS from a parametric route into a bare static path:

App/src/ROUTES.ts

Lines 961 to 964 in 2e03359

	SEARCH_ADVANCED_FILTERS: 'search/filters',
	SEARCH_ADVANCED_FILTERS_CONTENT: {
	route: 'search/filters/:filterKey',
	getRoute: (filterKey: SearchFilterKey | UserFriendlyKey) => `search/filters/${filterKey}` as const,

so the filters list page (ADVANCED_FILTERS_RHP → search/filters) is now a sibling of ADVANCED_FILTERS_CONTENT_RHP (search/filters/:filterKey) under the same modal navigator:

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

Lines 1974 to 1979 in 2e03359

	[SCREENS.RIGHT_MODAL.SEARCH_ADVANCED_FILTERS]: {
	screens: {
	[SCREENS.SEARCH.ADVANCED_FILTERS_RHP]: ROUTES.SEARCH_ADVANCED_FILTERS,
	[SCREENS.SEARCH.ADVANCED_FILTERS_CONTENT_RHP]: ROUTES.SEARCH_ADVANCED_FILTERS_CONTENT.route,
	},
	},

Because search/filters no longer resolves cleanly to ADVANCED_FILTERS_RHP, the focused RHP route at rebuild time is not one of the names listed in SEARCH_TO_RHP:

App/src/libs/Navigation/linkingConfig/RELATIONS/SEARCH_TO_RHP.ts

Lines 14 to 15 in 2e03359

	SCREENS.SEARCH.ADVANCED_FILTERS_RHP,
	SCREENS.SEARCH.ADVANCED_FILTERS_CONTENT_RHP,

So getMatchingFullScreenRoute returns undefined → the right‑modal fallback runs → Concierge is shown under the filters RHP instead of the Search page. Chain: bare search/filters no longer maps to ADVANCED_FILTERS_RHP → focused route missing from RHP_TO_SEARCH → getMatchingFullScreenRoute returns undefined → getAdaptedState defaults to REPORTS_SPLIT_NAVIGATOR (Concierge).

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

Make SEARCH_ADVANCED_FILTERS resolve unambiguously to the ADVANCED_FILTERS_RHP screen again so its focused route is recognized by RHP_TO_SEARCH. The simplest is to stop the list path from colliding with its :filterKey sibling — either restore the route‑object/parametric form the PR removed, or register the list page on a path that is not a prefix of search/filters/:filterKey. After the change, verify that getMatchingFullScreenRoute returns the Search full‑screen route for the filters RHP (so the right‑modal fallback never runs).

What alternative solutions did you explore? (Optional)

Harden the fallback in getAdaptedState: before defaulting to REPORTS_SPLIT_NAVIGATOR, resolve the open RHP through its own RHP_TO_* relation (here RHP_TO_SEARCH) so a known search RHP always lands on the Search tab rather than Concierge.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-30 16:49:54 UTC.

Proposal

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

After completing Track onboarding and dismissing the Concierge Side Panel on a wide screen, resizing the window to a narrow layout re-opens the Concierge Side Panel instead of leaving the Spend/Filter page visible.

What is the root cause of that problem?

The Side Panel stores its visibility in NVP_SIDE_PANEL as two independent flags — open (read on extra-large screens) and openNarrowScreen (read on everything else). useSidePanelDisplayStatus switches which flag it reads based on the current breakpoint:

App/src/hooks/useSidePanelDisplayStatus.tsx

Line 19 in 58045b3

const isSidePanelVisible = isExtraLargeScreenWidth ? sidePanelNVP?.open : sidePanelNVP?.openNarrowScreen;

The bug is an asymmetry between how these flags are written and cleared. openSidePanel can set both flags, but closeSidePanel only ever clears the one for the current layout:

App/src/libs/actions/SidePanel.ts

Lines 9 to 19 in 58045b3

	function openSidePanel(shouldOpenOnNarrowScreen: boolean) {
	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldOpenOnNarrowScreen ? {open: true, openNarrowScreen: true} : {open: true});
	}
	/**
	* Close the side panel
	*
	* @param shouldCloseOnNarrowScreen - Whether to close the side panel on narrow screen
	*/
	function closeSidePanel(shouldCloseOnNarrowScreen: boolean) {
	Onyx.merge(ONYXKEYS.NVP_SIDE_PANEL, shouldCloseOnNarrowScreen ? {openNarrowScreen: false} : {open: false});

The Track onboarding variant opens the panel with a hardcoded openSidePanel(true), so on a wide screen the NVP becomes {open: true, openNarrowScreen: true}:

App/src/components/SidePanel/RHPVariantTest/index.ts

Lines 64 to 66 in 58045b3

	if (variant === CONST.ONBOARDING_RHP_VARIANT.TRACK_EXPENSES_WITH_CONCIERGE) {
	Navigation.navigate(ROUTES.HOME);
	SidePanelActions.openSidePanel(true);

When the user dismisses on that wide screen, SidePanelContextProvider.closeSidePanel calls closeSidePanel(!isExtraLargeScreenWidth) → closeSidePanel(false), which merges {open: false} only and leaves openNarrowScreen: true stale:

App/src/components/SidePanel/SidePanelContextProvider.tsx

Lines 132 to 140 in 58045b3

	const closeSidePanel = (options?: {afterTransition?: () => void}) => {
	// User shouldn't be able to close side panel if side panel NVP is undefined
	if (!sidePanelNVP) {
	return;
	}
	onCloseCompleteRef.current = options?.afterTransition;
	setIsSidePanelTransitionEnded(false);
	SidePanelActions.closeSidePanel(!isExtraLargeScreenWidth);

Resizing to narrow flips the visibility gate to read openNarrowScreen (still true), so the Concierge Side Panel re-appears over the Spend/Filter page. Nothing was navigated — the panel re-shows purely because of the stale flag.

The asymmetry is symmetric in both directions: open on narrow, resize to wide, then dismiss → closeSidePanel(true) clears only openNarrowScreen and leaves open: true stale, so resizing back re-opens the panel the same way. The defect is the open/close flag asymmetry itself, not just the onboarding caller.

The auto-linked PR #94785 (cleanup of old search-filter routes) is unrelated — it has no Side Panel / NVP_SIDE_PANEL interaction. The regression lives entirely in the Side Panel flag handling above.

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

An explicit user dismissal should mean "closed" independent of the current layout, so it must clear both flags. We can't make closeSidePanel(shouldCloseOnNarrowScreen) blanket-clear both, because the route-change cleanup closeSidePanelOnNarrowScreen deliberately closes only the narrow flag while keeping the panel open on wide during in-app navigation:

App/src/libs/Navigation/Navigation.ts

Lines 201 to 220 in 58045b3

	function closeSidePanelOnNarrowScreen(route: Route) {
	const isExtraLargeScreenWidth = Dimensions.get('window').width > variables.sidePanelResponsiveWidthBreakpoint;
	if (!sidePanelNVP?.openNarrowScreen || isExtraLargeScreenWidth) {
	return;
	}
	// Split "r/:reportID/attachment/add" by ":reportID" to get the prefix "r/" and suffix "/attachment/add"
	const addAttachmentPrefix = ROUTES.REPORT_ADD_ATTACHMENT.route.split(':reportID').at(0) ?? '';
	const addAttachmentSuffix = ROUTES.REPORT_ADD_ATTACHMENT.route.split(':reportID').at(1) ?? '';
	const attachmentPreviewRoute = ROUTES.REPORT_ATTACHMENTS.route;
	const isAddingAttachment = typeof route === 'string' && route.startsWith(addAttachmentPrefix) && route.includes(addAttachmentSuffix);
	const isPreviewingAttachment = typeof route === 'string' && route.startsWith(attachmentPreviewRoute);
	// If the user is navigating to an attachment route (previewing or adding), keep the side panel open
	// so they still have access to the chat.
	if (isAddingAttachment || isPreviewingAttachment) {
	return;
	}
	SidePanelActions.closeSidePanel(true);

So separate the two intents:

• Keep the existing layout-scoped closeSidePanel for the automatic route-cleanup path (closeSidePanelOnNarrowScreen) unchanged.
• For the explicit user dismissal in SidePanelContextProvider.closeSidePanel, clear both flags unconditionally — e.g. a dedicated action that merges {open: false, openNarrowScreen: false} into NVP_SIDE_PANEL.

This fixes both directions of the asymmetry and leaves the navigation-cleanup behavior intact.

What specific scenarios should we cover in automated tests to prevent this from happening again?

• Unit: dismissing the Side Panel on a wide screen clears both open and openNarrowScreen; the symmetric narrow-screen dismissal does the same.
• Unit: the route-cleanup closeSidePanelOnNarrowScreen still clears only openNarrowScreen and keeps open on a wide screen.
• Regression: complete Track onboarding, dismiss Concierge on a wide screen, go to Spend, resize to narrow → the Spend/Filter page stays visible and the Side Panel does not re-open.

What alternative solutions did you explore? (Optional)

Fix the open side instead: make the onboarding variant open layout-aware like every other caller — openSidePanel(!isExtraLargeScreenWidth) in handleRHPVariantNavigation, computing the breakpoint the same way closeSidePanelOnNarrowScreen already does (Dimensions.get('window').width > variables.sidePanelResponsiveWidthBreakpoint). This stops the irrelevant openNarrowScreen flag from ever being written on a wide screen and fixes the reported flow, but it doesn't address the symmetric narrow-first case, so the close-side fix is the more complete root-cause change.