Onboarding-Not here page displayed after click on Workspace tab after onboarding flow

[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.3.89-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-35249/41236697/1447302081?sort=-identifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Windows 11 Home/Chrome
App Component: User Settings

Action Performed:

1. Open https://staging.new.expensify.com/
2. Create a new Gmail account
3. Select 'Something Else' and complete the flow
4. Click on 'Workspace' tab on LHN

Expected Result:

Workspace list page is displayed

Actual Result:

Not here page is displayed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7166053_1780029902988.note_here_page.mp4

View all open jobs on GitHub

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

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

[melvin-bot]

Triggered auto assignment to @amyevans (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

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

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Hmm... it's not here" page is rendered by WorkspaceInitialPage.tsx:193, not by WorkspacesListPage. That means after clicking the Workspace tab, navigation lands inside a WORKSPACE_SPLIT_NAVIGATOR route carrying a policyID the user doesn't actually own — and LOOKING_AROUND ("Something else") onboarding never creates a workspace, so any restored workspace ID is guaranteed stale.

The restore mechanism is in useRestoreWorkspacesTabOnNavigate.ts → navigateToWorkspacesPage.ts → WorkspaceRouter.getInitialState(). It reads a stale /workspaces/<policyID> URL from sessionStorage[LAST_VISITED_PATH_WORKSPACES_TAB] (written by NavigationRoot.tsx:91) and rehydrates the WORKSPACE_SPLIT_NAVIGATOR with that policyID. navigateToWorkspacesPage has a guard at line 79 that's supposed to fall back to WORKSPACES_LIST when shouldShowPolicy === false, but the guard only runs when lastWorkspacesTabNavigatorRoute is resolved from live nav state — when the restore path goes through WorkspaceRouter.getInitialState from session storage, no such validation occurs, so a non-existent policyID rehydrates and WorkspaceInitialPage immediately renders the not-found view.

Suspected regression source: between the current production deploy (~9.3.85) and 9.3.89 staging, multiple PRs in this area landed — most likely candidates are #91796 (changes waitForProtectedRoutes timing) or the cluster of PRs around useRestoreWorkspacesTabOnNavigate.ts from 2026-05-13. Confirming the exact regressing PR requires inspecting sessionStorage[LAST_VISITED_PATH_WORKSPACES_TAB] in the failing browser session.

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

Validate the restored policyID against the user's policies collection before letting it rehydrate. Two minimal options:

1. In WorkspaceRouter.ts buildWorkspaceInitialStateFromSessionStorage: when the restored state contains a WORKSPACE_SPLIT_NAVIGATOR, read ONYXKEYS.COLLECTION.POLICY synchronously (Onyx supports this) and check shouldShowPolicy for the saved policyID. If not accessible, drop the split route and return only WORKSPACES_LIST. This is the smallest, most contained fix.

2. In NavigationRoot.tsx: skip saveWorkspacesTabPathToSessionStorage while onboarding is incomplete (check ONYXKEYS.NVP_ONBOARDING via hasCompletedGuidedSetupFlowSelector). This prevents the stale workspace path from being written in the first place.

Option 1 fixes the symptom for all paths (also stale post-deletion, post-leave, etc.); Option 2 fixes the specific onboarding flow. Recommend both — they're complementary.

What alternative solutions did you explore? (Optional)

Removing the latch at WorkspaceInitialPage.tsx:197-198 — but this only hides the flash, it doesn't address why we're landing on WorkspaceInitialPage for a phantom policy at all.

---

⚠️ Confidence: medium. The render-side path (WorkspaceInitialPage triggers Not here) and the restore-from-sessionStorage mechanism are clearly traced from the code. The exact PR that introduced the staging-only regression is not yet pinned — confirming requires inspecting sessionStorage[LAST_VISITED_PATH_WORKSPACES_TAB] mid-repro on staging.

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

[amyevans]

I can't reproduce the issue any longer. Looks like it was fixed by the revert here: #92046