[Due for payment 2026-05-07] [Due for payment 2026-05-05] [$250] "Switch to Expensify Classic" button on Settings page leads to 404 due to missing entryScreen

@parasharrajat

Clicking the "Switch to Expensify Classic" button in the Settings menu leads to a 404 page instead of navigating to the exit survey.

Slack thread: https://expensify.slack.com/archives/C07NMDKEFMH/p1777307175469079

Root Cause

EXIT_SURVEY_REASON.entryScreens in ROUTES.ts:346-349 only permits Settings_Troubleshoot. However, the "Switch to Expensify Classic" button also exists on InitialSettingsPage.tsx:340-341, which calls createDynamicRoute(EXIT_SURVEY_REASON.path) without a basePath.

On wide screens, the default central pane is Settings_Profile (SettingsSplitNavigator.tsx:40), so createDynamicRoute builds settings/profile/exit-survey/reason. getStateFromPath then resolves Settings_Profile as the focused route, which is not in entryScreens, so it logs a warning and falls through to RNGetStateFromPath which can't match the path → 404.

The same button on TroubleshootPage.tsx:145 works fine because the focused route IS Settings_Troubleshoot.

Console warning: [getStateFromPath.ts][DynamicRoute] Focused route Settings_Profile is not allowed to access dynamic route with suffix exit-survey/reason - ""

Fix

Add SCREENS.SETTINGS.PROFILE.ROOT to EXIT_SURVEY_REASON.entryScreens in ROUTES.ts.

Proposal

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

When a user clicks "Switch to Expensify Classic" from the main Settings page (InitialSettingsPage), it causes a 404 instead of opening the exit survey, which prevents the user from completing the expected switch flow from that settings entry point.

What is the root cause of that problem?

The issue is caused by how dynamic settings routes are validated in src/ROUTES.ts and resolved from the current settings context. createDynamicRoute() builds the exit survey URL relative to the currently focused central pane screen, and getStateFromPath only allows that route when the focused screen is listed in the route's entryScreens configuration.

For DYNAMIC_ROUTES.EXIT_SURVEY_REASON in src/ROUTES.ts, entryScreens includes SCREENS.SETTINGS.TROUBLESHOOT but does not include SCREENS.SETTINGS.PROFILE.ROOT. On wide screens, SettingsSplitNavigator in src/libs/Navigation/AppNavigator/Navigators/SettingsSplitNavigator.tsx uses SCREENS.SETTINGS.PROFILE.ROOT as the defaultCentralScreen, so opening the survey from InitialSettingsPage resolves from Settings_Profile. Because that screen is not allowed in entryScreens, getStateFromPath rejects the route and the app falls through to an unmatched path, which results in the 404.

The same configuration gap exists for DYNAMIC_ROUTES.EXIT_SURVEY_CONFIRM in src/ROUTES.ts, whose entryScreens also omits SCREENS.SETTINGS.PROFILE.ROOT. As a result, the direct confirm-step path fails in the same way when InitialSettingsPage navigates there without first opening the reason step.

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

src/ROUTES.ts — add SCREENS.SETTINGS.PROFILE.ROOT to EXIT_SURVEY_REASON.entryScreens.
src/ROUTES.ts — add SCREENS.SETTINGS.PROFILE.ROOT to EXIT_SURVEY_CONFIRM.entryScreens.

What alternative solutions did you explore? (Optional)

Passing an explicit basePath of settings/troubleshoot to createDynamicRoute from InitialSettingsPage would force the route to resolve through the Troubleshoot screen. This was rejected because it hard-codes the main Settings page to a sibling screen's path and makes the flow depend on that URL structure instead of the route's own allowed entry screens.

Proposal

What is the root cause of that problem?

EXIT_SURVEY_REASON.entryScreens only permits Settings_Troubleshoot. On wide screens, the sidebar (InitialSettingsPage) and a central pane are rendered together. The default central pane is Settings_Profile (SettingsSplitNavigator.tsx:40).

When the user clicks "Switch to Expensify Classic" from the sidebar (InitialSettingsPage.tsx:340), createDynamicRoute builds the path relative to the current central pane (e.g. /settings/profile/exit-survey/reason). getStateFromPath then extracts Settings_Profile as the focused route, finds it's not in entryScreens, and the route falls through to a 404.

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

Add all settings central pane screens to EXIT_SURVEY_REASON.entryScreens in src/ROUTES.ts:346-349. The sidebar button can be clicked while any central pane is focused (not just Profile), so we need to allow all of them. The same fix should also be applied to EXIT_SURVEY_CONFIRM at line 350-353, since InitialSettingsPage can navigate directly to it as well (line 344).

Alternatively, if every settings screen should be able to reach the exit survey, using the wildcard '*' in entryScreens would be the simplest and most future-proof approach.

What alternative solutions did you explore? (Optional)

Adding only SCREENS.SETTINGS.PROFILE.ROOT (as suggested in the issue body) fixes the default case but leaves the bug reproducible when the user has navigated to any other central pane (Preferences, Wallet, Security, etc.) before clicking the sidebar button.

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.

Proposal

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

On wide layouts, clicking the Switch to Expensify Classic button on the Settings page (the entry shown in the general menu of InitialSettingsPage) navigates to a 404 page instead of opening the exit-survey reason step.

The same button on the Troubleshoot page works correctly, so the bug is specific to the entry point on the main Settings screen.

What is the root cause of that problem?

The handler that runs when the button is clicked builds the destination URL with createDynamicRoute:

App/src/pages/settings/InitialSettingsPage.tsx

Lines 339 to 345 in 626a3df

    
           resetExitSurveyForm(() => { 
        
               if (shouldOpenSurveyReasonPage) { 
        
                   Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.EXIT_SURVEY_REASON.path)); 
        
                   return; 
        
               } 
        
               Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.EXIT_SURVEY_CONFIRM.path)); 
        
           });

createDynamicRoute is called without an explicit basePath, so it defaults to Navigation.getActiveRoute() and concatenates the dynamic suffix to whatever URL is currently active:

App/src/libs/Navigation/helpers/dynamicRoutesUtils/createDynamicRoute.ts

Lines 64 to 73 in 626a3df

    
           const createDynamicRoute = (dynamicRouteSuffixWithParams: string, basePath?: string): Route => { 
        
               const [suffixPath] = splitPathAndQuery(dynamicRouteSuffixWithParams); 
        
               if (!suffixPath || !isDynamicRouteSuffix(suffixPath)) { 
        
                   throw new Error(`The route name ${suffixPath} is not supported in createDynamicRoute`); 
        
               } 
        
               const routePath = basePath ?? Navigation.getActiveRoute(); 
        
               return combinePathAndSuffix(routePath, dynamicRouteSuffixWithParams); 
        
           };

On wide layouts, the central pane of SettingsSplitNavigator defaults to Settings_Profile, so the active URL when the user is on Settings is /settings/profile:

App/src/libs/Navigation/AppNavigator/Navigators/SettingsSplitNavigator.tsx

Line 40 in 626a3df

defaultCentralScreen={SCREENS.SETTINGS.PROFILE.ROOT}

The combined target therefore becomes /settings/profile/exit-survey/reason. When getStateFromPath resolves that URL, the focused route is Settings_Profile, but the EXIT_SURVEY_REASON dynamic route only allows Settings_Troubleshoot as an entry screen:

App/src/ROUTES.ts

Lines 346 to 353 in 626a3df

    
           EXIT_SURVEY_REASON: { 
        
               path: 'exit-survey/reason', 
        
               entryScreens: [SCREENS.SETTINGS.TROUBLESHOOT], 
        
           }, 
        
           EXIT_SURVEY_CONFIRM: { 
        
               path: 'exit-survey/confirm', 
        
               entryScreens: [SCREENS.SETTINGS.DYNAMIC_EXIT_SURVEY_REASON, SCREENS.SETTINGS.TROUBLESHOOT], 
        
           },

Because Settings_Profile is not in entryScreens, the dynamic resolver logs a warning (Focused route Settings_Profile is not allowed to access dynamic route with suffix exit-survey/reason) and falls back to RNGetStateFromPath, which has no static match for settings/profile/exit-survey/reason and renders the 404 NotFoundPage.

The Troubleshoot version works because the user is already focused on Settings_Troubleshoot at the moment of the click, which is in the allow-list.

The same handler in InitialSettingsPage also has a second branch that navigates straight to EXIT_SURVEY_CONFIRM when the classic-redirect prompt was previously dismissed (shouldOpenSurveyReasonPage === false), and EXIT_SURVEY_CONFIRM.entryScreens has the same gap — it allows Dynamic_ExitSurvey_Reason and Settings_Troubleshoot but not Settings_Profile, so that branch 404s too once a user reaches it.

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

Add SCREENS.SETTINGS.PROFILE.ROOT to the entryScreens allow-list of both EXIT_SURVEY_REASON and EXIT_SURVEY_CONFIRM in src/ROUTES.ts. Both branches of the handler in InitialSettingsPage need to work, so both dynamic routes need the same entry screen registered.

After this change, when the button on the main Settings page builds /settings/profile/exit-survey/reason (or .../exit-survey/confirm), the dynamic resolver will accept Settings_Profile as a valid focused route, and getStateFromPath will return the correct state to render the exit-survey screen.

The Troubleshoot button is unaffected — Settings_Troubleshoot remains in the allow-list, so its behavior does not change.

Compare branch:
https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88986-exit-survey-profile-entry-screen?expand=1

What alternative solutions did you explore? (Optional)

Pass an explicit basePath such as ROUTES.SETTINGS into createDynamicRoute from the InitialSettingsPage handler so the resolved URL is always /settings/exit-survey/reason regardless of which central pane is active. This works but it requires changing call-site logic, and createDynamicRoute's allow-list mechanism is the intended place to declare which screens may launch a dynamic route — so configuring entryScreens is more in line with existing conventions.
Make EXIT_SURVEY_REASON.entryScreens accept the wildcard ['*'] as KEYBOARD_SHORTCUTS does. Rejected because it would silently widen the allow-list to every screen in the app and lose the safety net the explicit list is intended to provide.

@MelvinBot

@MelvinBot implement your proposal in a draft PR

Proposal

Root cause: Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.EXIT_SURVEY_REASON.path)) in InitialSettingsPage.tsx (lines 340–341) doesn't specify a base path, so createDynamicRoute resolves to the currently focused route. On wide screens the default central pane is Settings_Profile, which is not listed in EXIT_SURVEY_REASON.entryScreens in ROUTES.ts (lines 346–349) — causing the 404.

Fix: Add SCREENS.SETTINGS.PROFILE.ROOT to entryScreens for both EXIT_SURVEY_REASON and EXIT_SURVEY_CONFIRM in ROUTES.ts:

EXIT_SURVEY_REASON: {
    path: 'exit-survey/reason',
    entryScreens: [SCREENS.SETTINGS.TROUBLESHOOT, SCREENS.SETTINGS.PROFILE.ROOT],
},
EXIT_SURVEY_CONFIRM: {
    path: 'exit-survey/confirm',
    entryScreens: [SCREENS.SETTINGS.DYNAMIC_EXIT_SURVEY_REASON, SCREENS.SETTINGS.TROUBLESHOOT, SCREENS.SETTINGS.PROFILE.ROOT],
},

This mirrors the working behavior in TroubleshootPage.tsx and allows the exit survey flow to be triggered from InitialSettingsPage on wide screens without breaking existing behavior.

🤖 Draft PR created: #88990
Please mark it as "Ready for review" when it is ready for review.

Tested well for me, when I manually change the url to anything + exit-survey/reason

Reviewing label has been removed, please complete the "BugZero Checklist".

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.63-0 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

[CP Staging & Prod] Add Settings_Profile to exit survey entryScreens #88990

If no regressions arise, payment will be issued on 2026-05-05. 🎊

@mjasikowski

@mjasikowski / @youssef-lr The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.64-31 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

[CP Staging & Prod] Add Settings_Profile to exit survey entryScreens #88990

If no regressions arise, payment will be issued on 2026-05-07. 🎊

@mjasikowski

@mjasikowski / @youssef-lr The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

Navigation Menu

Repository navigation

[Due for payment 2026-05-07] [Due for payment 2026-05-05] [$250] "Switch to Expensify Classic" button on Settings page leads to 404 due to missing entryScreen #88986

Root Cause

Fix

Related

Proposal

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

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)

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)

Proposal

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

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)

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	resetExitSurveyForm(() => {
	if (shouldOpenSurveyReasonPage) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.EXIT_SURVEY_REASON.path));
	return;
	}
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.EXIT_SURVEY_CONFIRM.path));
	});

	const createDynamicRoute = (dynamicRouteSuffixWithParams: string, basePath?: string): Route => {
	const [suffixPath] = splitPathAndQuery(dynamicRouteSuffixWithParams);

	if (!suffixPath \|\| !isDynamicRouteSuffix(suffixPath)) {
	throw new Error(`The route name ${suffixPath} is not supported in createDynamicRoute`);
	}

	const routePath = basePath ?? Navigation.getActiveRoute();
	return combinePathAndSuffix(routePath, dynamicRouteSuffixWithParams);
	};

	EXIT_SURVEY_REASON: {
	path: 'exit-survey/reason',
	entryScreens: [SCREENS.SETTINGS.TROUBLESHOOT],
	},
	EXIT_SURVEY_CONFIRM: {
	path: 'exit-survey/confirm',
	entryScreens: [SCREENS.SETTINGS.DYNAMIC_EXIT_SURVEY_REASON, SCREENS.SETTINGS.TROUBLESHOOT],
	},

[Due for payment 2026-05-07] [Due for payment 2026-05-05] [$250] "Switch to Expensify Classic" button on Settings page leads to 404 due to missing entryScreen #88986

Description

Root Cause

Fix

Related

Activity

melvin-bot commented on Apr 27, 2026

melvin-bot commented on Apr 27, 2026

aswin-s commented on Apr 27, 2026

Proposal

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

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)

MelvinBot commented on Apr 27, 2026

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)

wildan-m commented on Apr 27, 2026

Proposal

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

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)

mjasikowski commented on Apr 27, 2026

Guidondor commented on Apr 27, 2026

MelvinBot commented on Apr 27, 2026

4 remaining items

youssef-lr commented on Apr 28, 2026

melvin-bot commented on Apr 28, 2026

melvin-bot commented on Apr 28, 2026

melvin-bot commented on Apr 28, 2026

melvin-bot commented on Apr 30, 2026

melvin-bot commented on Apr 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions