Workspace Settings - Double tapping on a category row leads to Not Here page

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.72-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: https://test-management.browserstack.com/projects/2219752/test-runs/72388032/folder/53695398/41236866/1726842510
Email or phone of affected tester (no customers): applausetester+bm985a@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: mweb
App Component: Workspace Settings

Action Performed:

1. Go to staging.new.expensify.com
2. Create a workspace.
3. Go to Categories.
4. Double tap on any category.
5. When Not Here page appears, navigate back.
6. Single tap on any category or the Add category button.

Expected Result:

Not Here page should not appear.

Actual Result:

Not Here page appears.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @dmkt9

[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/274dac1e43c4a253a399294a6007e70158d687f2029a5f61930a098e65821108

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Not Here" page is not coming from the category page's own guards — it is the root NOT_FOUND wildcard screen, produced by a malformed URL that the second tap builds.

WorkspaceCategoriesPage builds every navigation target at press time with a bare createDynamicRoute(suffix), with no basePath:

• src/pages/workspace/categories/WorkspaceCategoriesPage.tsx:221-230 — category row
• src/pages/workspace/categories/WorkspaceCategoriesPage.tsx:318-320 — Add category

Without a basePath, createDynamicRoute appends the suffix to Navigation.getActiveRoute() — whatever route is active at that instant. Its own docstring warns about this.

So on a double tap:

1. Tap 1 → base is .../categories → navigates to .../categories/category/Advertising. The settings page is an RHP, so the list stays mounted and pressable underneath.
2. Tap 2 (~100–300ms later, after tap 1 committed) → base is now .../categories/category/Advertising → builds .../categories/category/Advertising/category/Advertising.
3. getStateFromPath strips the trailing suffix, resolves the base to Dynamic_Category_Settings, and checks entryScreens — which is [SCREENS.WORKSPACE.CATEGORIES] only (ROUTES.ts:962-966). Validation fails.
4. It falls through to the wildcard [SCREENS.NOT_FOUND]: '*' → "Hmm... it's not here".

This is why the bug then spreads to the Add category button. All buttons on the page share one global input — the active route. As long as it still contains /category/<name> after the back press, every subsequent press re-fails the same check: WORKSPACE_CATEGORY_CREATE also declares entryScreens: [SCREENS.WORKSPACE.CATEGORIES] (ROUTES.ts:1100-1103). A per-row or duplicate-push theory cannot explain that spread; this one does.

The repo already has a test asserting this exact failure, tests/navigation/useScreenBoundDynamicRouteTests.tsx:107-121 — "keeps the base path once another screen is stacked over it":

// Without the binding the suffix lands on whatever screen is active instead.
expect(JSON.stringify(getStateFromPath(createDynamicRoute(CARD_DETAILS)))).toContain('not-found');

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

Bind the base path to the categories screen's own route instead of reading the live active route. The hook for this already exists: useScreenBoundDynamicRoute, which latches the base via useFocusEffect so a stacked RHP cannot poison it.

In WorkspaceCategoriesPage, call the hook once and use it for both navigateToCategory and navigateToCreateCategoryPage (and navigateToCategoriesSettings / import, which share the pattern). The second tap then rebuilds the same path as the first, which react-navigation already dedupes to a no-op.

Note useSingleExecution is not a valid fix here — it is a no-op on web (src/hooks/useSingleExecution/index.ts:10-20), and this is reported on mWeb Safari.

Wider scope: this is a class of bug, not a categories-only one. WorkspaceTagsPage.tsx:325-331 has the identical pattern, and only 13 files in the repo use the safe hook. Whoever picks this up should decide whether to fix just categories or sweep the sibling list pages.

What alternative solutions did you explore? (Optional)

Alternatives considered and evidence

Alternatives ruled out:

• Duplicate push of the same route — already suppressed by areNamesAndParamsEqual in linkTo/index.ts:190-193. An identical duplicate is a no-op, so the bug requires a different path — which is what the doubled suffix is.
• A stuck isNavigating / isExecuting flag — no such flag exists; useSingleExecution is a no-op on web.
• Lazy-load failure in the Dynamic* pages — they are synchronous require() screens, no React.lazy/Suspense. "Dynamic" refers to dynamic routes, not dynamic imports.
• policyCategories not yet loaded — a missing categories list routes to a loading indicator, not to Not Here. CategorySettingsPage.tsx:283-285 is a genuine second source of the same page, but it does not explain the Add-category button breaking.

Alternative fix shape: make createDynamicRoute itself reject a base whose focused screen is not in the suffix's entryScreens, rather than silently producing a Not Here. That is a broader change and would need its own discussion.

Repro attempt: an automated pass on dev web could not reproduce the literal Not Here page. That harness only sends synthetic mouse clicks in Chromium at a desktop split-pane layout — it cannot emulate iOS Safari touch timing, and double-tap is explicitly unsupported for web there. At a mobile-width viewport a fast second tap did land on unintended controls on the newly-opened screen, confirming the underlying "second tap fires after the first navigation committed" timing hazard. So the code trace is not contradicted by the failed repro; it just was not independently confirmed at runtime.

Confirming in production: getStateFromPath.ts:67-71 logs [getStateFromPath.ts][DynamicRoute] None of the N dynamic suffix candidate(s) passed entryScreens validation for path: <PATH>. That line prints the offending path verbatim and would confirm frequency and how far the pattern spreads beyond categories.

Confidence: High on the mechanism for the first Not Here (traced end to end, and asserted by an existing test). Medium on precisely why the active route stays polluted across the back press — the three candidates are a lingering RHP route, a lingering root-level NOT_FOUND route (getActiveRoute() would return /not-found), or the documented late-popstate desync on web that "reset the app to a stale route". All three break identically, so the fix is the same either way.

---

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

---

view run · no recording available

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[mukhrr]

@roryabraham i think this is of same bug family from #95364 and we can do this as follow up for #98406? cc @dmkt9