[$250] [Exploratory] Web - Upgrade flow - Currency settings leads to page not found

[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.19-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92161
Email or phone of affected tester (no customers): testing210790@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Windows 11, Samsung a31
App Component: Other

Action Performed:

1. Create a fresh account.
2. Start onboarding flow.
3. Select “Submit expenses to my employer”.
4. Complete onboarding.
5. On the expense creation flow, proceed to the Category step.
6. Trigger the Upgrade / workspace creation prompt.
7. Proceed with the upgrade process.
8. Before completing workspace creation, attempt to access or change the workspace currency settings.

Expected Result:

The currency settings page should load correctly or the user should be guided through a valid workspace setup flow without navigation errors.

Actual Result:

The application redirects to a Page Not Found (404) when trying to access or change the workspace currency settings during the upgrade flow before the workspace is fully created. This breaks the flow and prevents the user from continuing the setup process.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7190302_1782339219419.Grabando__920.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7190302

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077911358039243515
• Upwork Job ID: 2077911358039243515
• Last Price Increase: 2026-07-24

Issue Owner

Current Issue Owner: @wildan-m

[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/109229d0b142c86a51b793fce4a41fe93936efb23924c8c703d75057f5ea8b72

https://platform.applause.com/services/links/v1/external/0ebfd128f1226075d8ba385d1ff55edb644cd4c1ad8b4d3fc911662f385b64a4

https://platform.applause.com/services/links/v1/external/140c40c593171f320266246b1764b11888b23b9a1ab18e1f63e02a3381a16c4d

[MelvinBot]

Proposal

What is the root cause of that problem?

The workspace currency page is wrapped in AccessOrNotFoundWrapper, which renders the 404 (NotFoundPage) whenever isPolicyAccessible(policy, login) is false.

During the onboarding upgrade / workspace-creation flow, the workspace's policy object in Onyx is still absent or only a partial/optimistic object (no valid id, no user role) until the backend confirms creation. isPolicyAccessible requires the policy to be non-empty and have a real id and grant the user a role — so mid-creation it returns false and the wrapper short-circuits to the 404 before the page ever renders.

The loading fallback doesn't save it either: shouldShowFullScreenLoadingIndicator only shows the spinner while report data is loading and the policy is empty. Once report data finishes loading but the policy still isn't accessible (exactly the creation window), it falls through to the 404 instead of the loader.

Investigation details & evidence

• Route/screen: WorkspaceOverviewCurrencyPage.tsx, route workspaces/:policyID/overview/currency (ROUTES.ts:2285-2294).
• Guard: AccessOrNotFoundWrapper.tsx:217 computes isPolicyNotAccessible; lines 221-222 feed it into shouldShowNotFoundPage, which renders NotFoundPage.
• Navigation in: WorkspaceOverviewPage.tsx:136-141 — onPressCurrency guards only on !policyID, not on whether the policy is actually created/accessible. So reaching the overview page for a not-yet-created workspace and tapping Currency navigates straight into the 404.
• Upgrade flow (WorkspaceUpgradePage.tsx, triggered from the Category step CategorySettingsPage.tsx:322) assumes the policy already exists and keys all its actions by that policyID.

Alternative explanations considered: a genuinely bad/expired route or a deleted policy would also 404, but the reproduction (a brand-new workspace being created) points squarely at the "policy not accessible yet" window rather than a stale/deleted policy.

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

Two complementary options:

1. Most targeted — treat "still creating" as loading, not 404. In AccessOrNotFoundWrapper, broaden the loading condition so a policy that is pending creation (policy.isLoading, a pending-add pendingAction, or a policy whose id isn't present yet) shows the full-screen loading indicator instead of immediately failing isPolicyNotAccessible. This keeps the user on a spinner until creation resolves.

2. Additionally — gate the entry point. In WorkspaceOverviewPage.onPressCurrency, gate navigation on the policy being accessible (not just !policyID), matching the guard the currency page itself expects.

What alternative solutions did you explore? (Optional)

Blocking access to workspace settings pages entirely until workspace creation confirms — heavier and affects the whole settings surface, so the scoped loading-state fix above is preferred.

---

Note: I couldn't confirm from production logs exactly which condition in isPolicyAccessible fails at repro time (empty policy vs. missing id vs. missing role) — the guard mechanism and 404 path are certain, but the precise Onyx state at that moment is inferred. A repro requestID correlating the CreateWorkspace/upgradeSubmit response timing against the navigation to the currency route would nail it down.

I didn't find any existing open issue tracking this specific 404.

---

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

[melvin-bot]

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

[wildan-m]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-17 00:35:26 UTC.

Proposal

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

During the onboarding expense-creation flow, when the user triggers the workspace upgrade/creation prompt from the Category step, the Confirm Workspace panel is shown so they can name the workspace and pick a default currency. Tapping the Default currency row on that panel redirects to a Page Not Found (404) instead of opening the currency selector, breaking the setup flow.

What is the root cause of that problem?

The currency row on the Confirm Workspace panel is rendered by CurrencySelector with the useWorkspaceConfirmationCurrencySelector flag, so it navigates using a dynamic route that is appended to the currently active route:

App/src/components/CurrencySelector.tsx

Lines 91 to 96 in d5b7125

	onPress={() => {
	didOpenCurrencySelector.current = true;
	if (useWorkspaceConfirmationCurrencySelector) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.WORKSPACE_CONFIRMATION_CURRENCY.path));
	return;
	}

A dynamic route is only accepted if the screen the user is currently on is listed in that route's entryScreens allowlist. The WORKSPACE_CONFIRMATION_CURRENCY dynamic route only allows being opened from the standalone workspace-confirmation screen (SCREENS.WORKSPACE_CONFIRMATION.DYNAMIC_ROOT):

App/src/ROUTES.ts

Lines 139 to 142 in d5b7125

	WORKSPACE_CONFIRMATION_CURRENCY: {
	path: 'currency',
	entryScreens: [SCREENS.WORKSPACE_CONFIRMATION.DYNAMIC_ROOT],
	},

But the same WorkspaceConfirmationForm is also embedded inline inside the expense-creation upgrade step (IOURequestStepUpgrade), which is mounted under SCREENS.MONEY_REQUEST.STEP_UPGRADE:

App/src/pages/iou/request/step/IOURequestStepUpgrade.tsx

Lines 371 to 378 in d5b7125

	{!isUpgraded && showConfirmationForm && (
	<WorkspaceConfirmationForm
	policyOwnerEmail={session?.email ?? ''}
	onSubmit={onWorkspaceConfirmationSubmit}
	onBackButtonPress={() => setShowConfirmationForm(false)}
	addBottomSafeAreaPadding={false}
	/>
	)}

So when the currency row is tapped from inside the upgrade flow, the built path becomes <money-request/upgrade…path>/currency. During path resolution, the underlying focused screen (STEP_UPGRADE) is not in the route's entryScreens, so the dynamic-route match is rejected and the app falls back to the default parser, which cannot match the path and renders the Not Found page:

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

Lines 44 to 56 in d5b7125

	// to open this dynamic route (via entryScreens).
	const focusedRoute = findFocusedRouteWithOnyxTabGuard(getStateFromPath(pathWithoutDynamicSuffix) ?? {});
	const entryScreens: ReadonlyArray<Screen | '*'> = DYNAMIC_ROUTES[dynamicRoute as DynamicRouteKey]?.entryScreens ?? [];
	if (focusedRoute?.name && entryScreens.some((s) => s === '*' || s === focusedRoute.name)) {
	// Merge the base route's params with params extracted from the dynamic suffix.
	// This gives the dynamic route screen access to all context it needs.
	const mergedParams = {
	...(focusedRoute?.params as Record<string, unknown> | undefined),
	...pathParams,
	};
	return getStateForDynamicRoute(normalizedPath, dynamicRoute as DynamicRouteKey, mergedParams, strippedTabPath);
	}

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

Add SCREENS.MONEY_REQUEST.STEP_UPGRADE to the entryScreens array of the WORKSPACE_CONFIRMATION_CURRENCY dynamic route in src/ROUTES.ts, so that opening the currency selector is allowed when the Confirm Workspace form is shown inside the expense-creation upgrade step:

App/src/ROUTES.ts

Lines 139 to 142 in d5b7125

	WORKSPACE_CONFIRMATION_CURRENCY: {
	path: 'currency',
	entryScreens: [SCREENS.WORKSPACE_CONFIRMATION.DYNAMIC_ROOT],
	},

The list would become [SCREENS.WORKSPACE_CONFIRMATION.DYNAMIC_ROOT, SCREENS.MONEY_REQUEST.STEP_UPGRADE]. With the launching screen allowlisted, getStateFromPath accepts the …/currency dynamic route and renders the workspace currency selection page. The currency selection reads from and writes to the shared WORKSPACE_CONFIRMATION_FORM_DRAFT Onyx draft, so the chosen currency is correctly reflected back on the Confirm Workspace panel.

Note on scope: this issue was reported against PR #92161, whose money-request migration has since been reverted from main. The bug still reproduces on current main — the reverted work only changed which screen hosts the upgrade step, not the underlying entryScreens mismatch, so the fix targets the screen that main actually uses today (STEP_UPGRADE).

WorkspaceConfirmationForm is embedded on one other surface (the Travel confirmation page, SCREENS.TRAVEL.WORKSPACE_CONFIRMATION), which is likewise absent from this allowlist and would hit the same 404 if its currency row is reachable. I've kept this fix scoped to the reported flow, and I'm happy to allowlist that screen too if we'd like to cover it in the same PR.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/94530-upgrade-flow-currency-not-found?expand=1

What alternative solutions did you explore? (Optional)

Conditionally disabling the dynamic currency route inside the upgrade flow and falling back to the non-dynamic currency selector was considered, but that selector targets a different screen/back-path and would not write to the workspace-confirmation form draft, so the picked currency would not persist back onto the panel. Allowlisting the launching screen via entryScreens is the minimal change that matches the existing dynamic-route design and keeps the form draft as the single source of truth.

[melvin-bot]

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