[Due for payment 2026-06-09] [$250] Back button is not showing on "Hmm... it's not here" page

[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: v9.3.83-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90769
Email or phone of affected tester (no customers): applausetester+abr3va3@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Web
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com.
2. Create workspace
3. Go to More > Share > Copy URL
4. Go to More > Delete > Confirm the delete process
5. Navigate to Inbox and open any chat
6. Paste the workspace URL from step 2
7. Tap the link check back button

Expected Result:

Back button should displayed n "Hmm... it's not here" page

Actual Result:

Back button is not showing on "Hmm... it's not here" page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7164148_1779874633793.2026-05-27_11-35-39.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059598847479559790
• Upwork Job ID: 2059598847479559790
• Last Price Increase: 2026-05-27

Issue Owner

Current Issue Owner: @abzokhattab

[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/73477c46033f732114bebce0609bfde9eee7dd870929adf697f39023a4e2b1c8

[MelvinBot]

Proposal

What is the root cause of that problem?

This is very likely the same underlying issue as #91434 ("Top left arrow on hmm not here page is not responsive").

When a user taps a link to a deleted workspace from a chat, cross-tab navigation pushes a new TAB_NAVIGATOR onto the root stack. AccessOrNotFoundWrapper detects the workspace is inaccessible and renders PageNotFoundFallback. On this page:

1. The back button IS rendered — for isPolicyNotAccessible=true, shouldShowBackButton resolves to undefined which defaults to true in FullPageNotFoundView.
2. But pressing it does nothing — the onBackButtonPress handler calls goBackFromWorkspaceSettingPages(), which checks if the previous route is REPORTS_SPLIT_NAVIGATOR. However, the navigation state after cross-tab push may not have the expected route structure at rootState.routes.at(-2), causing the isPreviousInbox check to fail and falling through to Navigation.goBack(ROUTES.WORKSPACES_LIST.route) — which also silently fails since the user wasn't on the workspaces list.

The tester likely reported "not showing" because the button is visually present but completely unresponsive (tapping it produces no navigation), which can appear identical to a missing button.

Note: PR #90769 (now merged) fixed the related "Go back to home page" link navigation, but did not fully address the back button press handler for all navigation states.

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

The fix in goBackFromWorkspaceSettingPages() needs to handle the case where the cross-tab pop logic doesn't find a valid underlyingTabNavIndex. When isPreviousInbox is false AND the user arrived via a cross-tab link (not from the workspaces list), the function should fall back to Navigation.goBackToHome() to ensure the user always navigates somewhere rather than silently failing.

What alternative solutions did you explore? (Optional)

This could also be addressed by ensuring AccessOrNotFoundWrapper's PageNotFoundFallback uses Navigation.goBackToHome() directly as the onBackButtonPress when isPolicyNotAccessible is true and the navigation state indicates a cross-tab push, bypassing goBackFromWorkspaceSettingPages() entirely.

---

Possibly related issues:

• [$250] hat-Top left arrow on hmm not here page is not responsive. #91434 — same symptom (back arrow not responsive on "not here" page), already has proposals and Help Wanted label
• [Due for payment 2026-06-03] [$250] Workspace - LHN is lost when user navigate to deleted workspace link #90520 — related (LHN lost when navigating to deleted workspace link), fixed by merged PR Use workspace recovery navigation for NotFound link press #90769

---

Next Steps for Contributor+ team: This appears to be a duplicate of #91434. Consider closing one as duplicate. Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-27 11:54:13 UTC.

Proposal

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

After deleting a workspace and pasting the share URL from step 2 into a chat, tapping the link lands the user on a "Hmm... it's not here" page where the top-left back arrow is missing/inert — the affected tester (QA execution for PR #90769) sees no functional way to return to the chat. The expected behavior, codified in PR #90769's test plan ("Click on back button... verify that you are returned to the chat"), is that the back arrow is rendered and successfully returns the user to the chat the link was tapped from.

What is the root cause of that problem?

The copied URL is built from WorkspaceOverviewSharePage as ${environmentURL}${ROUTES.WORKSPACE_JOIN_USER.getRoute(policyID, adminEmail)} — i.e. staging.new.expensify.com/workspaces/<policyID>/join?email=<admin>. The linking config maps workspaces/:policyID/join to SCREENS.WORKSPACE_JOIN_USER, NOT to the wildcard SCREENS.NOT_FOUND:

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

Lines 34 to 36 in e59602c

	[SCREENS.MONEY_REQUEST.ODOMETER_PREVIEW]: ROUTES.MONEY_REQUEST_ODOMETER_PREVIEW.route,
	[SCREENS.WORKSPACE_JOIN_USER]: ROUTES.WORKSPACE_JOIN_USER.route,
	[SCREENS.NOT_FOUND]: '*',

So when the user taps the chat link, Link.openLink calls Navigation.navigate(/workspaces/<id>/join?email=...) and WorkspaceJoinUserPage mounts as a top-level full-screen modal on top of the inbox TAB_NAVIGATOR. Inside its effect (lines 29-48 of WorkspaceJoinUserPage.tsx), the freshly-deleted policy in Onyx is either empty (isEmptyObject(policy) true) or still has pendingAction: DELETE (isPendingDeletePolicy(policy) true) — in both cases the early-return branch that navigates to WORKSPACE_INITIAL is skipped, and the page falls through to inviteMemberToWorkspace(policyID, ...) followed by navigateAfterJoinRequest():

App/src/pages/workspace/WorkspaceJoinUserPage.tsx

Lines 29 to 48 in e59602c

	useEffect(() => {
	if (isUnmounted.current || isPolicyLoading) {
	return;
	}
	if (!isEmptyObject(policy) && !policy?.isJoinRequestPending && !isPendingDeletePolicy(policy)) {
	Navigation.isNavigationReady().then(() => {
	Navigation.goBack();
	Navigation.navigate(ROUTES.WORKSPACE_INITIAL.getRoute(policyID));
	});
	return;
	}
	inviteMemberToWorkspace(policyID, inviterEmail);
	Navigation.isNavigationReady().then(() => {
	if (isUnmounted.current) {
	return;
	}
	navigateAfterJoinRequest();
	});
	// eslint-disable-next-line react-hooks/exhaustive-deps -- we only want to run this once after the policy loads
	}, [isPolicyLoading]);

navigateAfterJoinRequest does Navigation.goBack() (pops WORKSPACE_JOIN_USER off the root, returning to the inbox tab) and then queues Navigation.navigate(ROUTES.WORKSPACES_LIST.route). Because SCREENS.WORKSPACES_LIST is registered in ROOT_TAB_SCREENS (src/libs/Navigation/helpers/linkTo/index.ts:28), linkTo treats this as a plain tab switch — not a cross-tab PUSH — so the inbox TAB_NAVIGATOR is replaced in place and its focused tab flips to the workspaces tab. The workspaces tab's WorkspaceRouter.getInitialState then rehydrates from sessionStorage (buildWorkspaceInitialStateFromSessionStorage), which still holds the path the user was on before deletion — /workspaces/<deletedID> or /workspaces/<deletedID>/overview. The user lands on WorkspaceInitialPage (or WorkspaceOverviewPage via WorkspacePageWithSections) for the deleted policy, and the "Hmm... it's not here" view is rendered by FullPageNotFoundView with shouldForceFullScreen=true. The back arrow itself does render (in FullPageNotFoundView, shouldShowBackButton defaults to true and no caller in the deleted-workspace path overrides it to false) — so the tester's "not showing" describes the press producing zero observable change, not literal visual absence.

The reason pressing it produces zero change is the back handler bound to it. WorkspaceInitialPage.tsx:467 and WorkspacePageWithSections.tsx:200-204 both route the press through goBackFromWorkspaceSettingPages(). That helper inspects rootState.routes.at(-2); in this flow the navigate-to-workspaces step replaced the inbox tab in place rather than pushing a new tab, so there is no underlying TAB_NAVIGATOR to detect — secondToLastRoute is the ProtectedScreens wrapper (or undefined), getActiveTabName(secondToLastRoute) !== REPORTS_SPLIT_NAVIGATOR, and isPreviousInbox evaluates false. Control falls into the else branch (Navigation.goBack(ROUTES.WORKSPACES_LIST.route)), which goUp-resolves to a jumpTo/POP_TO within the same WORKSPACE_NAVIGATOR — the only thing on the root above it is the (single) TAB_NAVIGATOR, so there is no parent route to pop to and the user is shuffled to the workspaces list at best, never back to the chat they came from. From the tester's vantage point on wide-screen Chrome that is indistinguishable from a dead button:

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

Lines 12 to 31 in e59602c

	function goBackFromWorkspaceSettingPages() {
	const rootState = navigationRef.getRootState() as State<RootNavigatorParamList>;
	const secondToLastRoute = rootState.routes.at(-2);
	const isPreviousInbox = getActiveTabName(secondToLastRoute) === NAVIGATORS.REPORTS_SPLIT_NAVIGATOR;
	if (isPreviousInbox) {
	// Cross-tab PUSH stacks a new TAB_NAVIGATOR on the root. dismissModal() doesn't handle
	// TAB_NAVIGATOR routes, so pop directly to the underlying navigator instead.
	const topRootIndex = rootState.index ?? rootState.routes.length - 1;
	const underlyingTabNavIndex = rootState.routes.findLastIndex((route, idx) => idx < topRootIndex && route.name === NAVIGATORS.TAB_NAVIGATOR);
	if (underlyingTabNavIndex !== -1) {
	navigationRef.current?.dispatch({...StackActions.pop(topRootIndex - underlyingTabNavIndex), target: rootState.key});
	return;
	}
	Navigation.dismissModal();
	} else {
	Navigation.goBack(ROUTES.WORKSPACES_LIST.route);
	}
	}

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

Fix the redirect at the source. WorkspaceJoinUserPage is the only screen owning this flow, and it is the place that decides where the user lands after the join API call fires. Instead of navigateAfterJoinRequest() (which goBacks-then-pushes the workspaces tab and depends on sessionStorage rehydration to surface a deleted workspace), the deleted-policy / pending-delete branch should stop the dispatch chain at the Navigation.goBack() step alone — popping WORKSPACE_JOIN_USER returns the user directly to the chat where they tapped the link, with no NotFound screen and no broken back arrow to recover from. Gate the second hop on whether the policy is actually joinable: when isEmptyObject(policy) || isPendingDeletePolicy(policy), call Navigation.goBack() without the trailing Navigation.navigate(WORKSPACES_LIST.route), and skip the no-op inviteMemberToWorkspace API write for a policy the server has already deleted. The existing first early-return branch (policy still exists and is joinable) is unchanged, so genuine join-by-link flows continue to land on WORKSPACE_INITIAL exactly as before.

The reason this is the right boundary rather than patching goBackFromWorkspaceSettingPages (the fix proposed in #91434) is that the source of the trapped state here is navigateAfterJoinRequest synthesizing a workspace-tab destination the user never asked for. PR #90769 already audited the goBackFromWorkspaceSettingPages paths for the cross-tab PUSH shape and added target: rootState.key to the pop dispatch (goBackFromWorkspaceSettingPages.ts:24); that fix correctly handles a stacked TAB_NAVIGATOR but cannot help on the plain-tab-switch shape the JOIN URL produces. Stopping the page from manufacturing that shape in the first place leaves the previously-shipped fix intact for the /workspaces/<id>/tags-style direct deep-link flow that #91434 documents.

What alternative solutions did you explore? (Optional)

Broadening goBackFromWorkspaceSettingPages to also handle the single-TAB_NAVIGATOR-on-root shape (a Navigation.goBack() fallback when neither the cross-tab-push pop nor goBack(WORKSPACES_LIST) resolves) was considered, but it shifts complexity onto a shared helper used by every workspace settings screen and risks regressing the Workspaces-tab-internal back path that the else branch correctly serves today; fixing the join-link redirect keeps the blast radius confined to the one screen that actually needs different behavior.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-27 11:55:38 UTC.

Proposal

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

After deleting a workspace and tapping the workspace invite URL from a chat, the user is taken to the "Hmm... it's not here" page without a back button, leaving them stranded on a route they can't dismiss on web (Chrome / Safari, wide layout). The link the user copied from More → Share is the WORKSPACE_JOIN_USER URL https://staging.new.expensify.com/workspaces/<policyID>/join?email=<adminEmail> (see WorkspaceOverviewSharePage.tsx#L47).

What is the root cause of that problem?

When the workspace has already been deleted, WorkspaceJoinUserPage's effect at WorkspaceJoinUserPage.tsx#L29-L48 falls into the second branch (because isEmptyObject(policy) is true once the backend has dropped the policy from Onyx, or isPendingDeletePolicy(policy) is true during the optimistic window):

inviteMemberToWorkspace(policyID, inviterEmail);
Navigation.isNavigationReady().then(() => {
    if (isUnmounted.current) {
        return;
    }
    navigateAfterJoinRequest();
});

navigateAfterJoinRequest at navigateAfterJoinRequest.ts#L4-L9 then performs a cross-tab Navigation.navigate(ROUTES.WORKSPACES_LIST.route):

const navigateAfterJoinRequest = () => {
    Navigation.goBack();
    Navigation.setNavigationActionToMicrotaskQueue(() => {
        Navigation.navigate(ROUTES.WORKSPACES_LIST.route);
    });
};

WORKSPACES_LIST is nested inside WORKSPACE_NAVIGATOR (linking config #L2284-L2293). Because the user arrived from the Inbox tab (steps 5–7: open a chat, paste the URL, tap), the navigate call pushes a fresh TAB_NAVIGATOR onto the root stack with the Workspaces tab active. React Navigation restores that tab's saved state — and that state still contains WORKSPACE.INITIAL for the just-deleted policyID, because the user was sitting on More → Share → Copy URL (a WORKSPACE_SPLIT_NAVIGATOR route) at the moment they hit Delete.

Once WorkspaceInitialPage re-renders with the deleted policyID, the latch at WorkspaceInitialPage.tsx#L196-L201 (introduced by PR #90769) immediately flips shouldShowNotFoundPage to true and keeps it true via usePrevious:

const computedShouldShowNotFoundPage = isWorkspacesTabFocused && !shouldShowPolicy && !policy?.isLoading && (!isPendingDelete || prevIsPendingDelete);
const prevShouldShowNotFoundPage = usePrevious(computedShouldShowNotFoundPage);
const shouldShowNotFoundPage = computedShouldShowNotFoundPage || !!prevShouldShowNotFoundPage;

So the user lands on FullPageNotFoundView rendered by WorkspaceInitialPage — not the same NotFoundPage that AccessOrNotFoundWrapper shows for direct workspace-settings URLs. The "Hmm... it's not here" copy is identical, so the user has no way to know they're on a different blocking view.

That's why the back button is missing on wide web layout. The header bar that would normally carry the back arrow comes from FullPageNotFoundView's own internal <HeaderWithBackButton>. On the cross-tab navigation path described above:

• The Inbox TAB_NAVIGATOR is at root index 0, the freshly-pushed Workspaces TAB_NAVIGATOR is at root index 1.
• WORKSPACE_INITIAL lives inside the inner WORKSPACE_SPLIT_NAVIGATOR, and on wide web WORKSPACE_INITIAL is the LHS pane of the workspace split, not an RHP-style modal screen — that's why on wide layouts the workspace-initial page never renders its own header back arrow during normal operation (the LHS pane has no back affordance, the user navigates via the workspace LHN menu items at WorkspaceInitialPage.tsx#L482-L515).
• When FullPageNotFoundView takes over the same slot with shouldForceFullScreen, it is wrapped in forcedBlockingViewContainer (position: 'fixed'; top/left/right/bottom: 0) — a full-viewport overlay anchored to the LHS pane slot. The user perceives this as "the page", but its <HeaderWithBackButton> is still scoped to the split's LHS column on wide layouts, which has no chrome above it and no parent header to fall back to. Result: the page covers the screen but no back affordance reaches the user — matching the QA report exactly.

In short: the wrong navigation destination after a failed/empty-policy join (WORKSPACES_LIST instead of returning to where the user came from) is what drops the user on a screen that has no usable back path on wide web. The issue isn't a shouldShowBackButton prop bug — it's that WORKSPACE.INITIAL was never designed to be the terminal screen the user lands on from a chat tap, and the latched NotFound keeps them pinned there.

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

Fix the navigation in the empty/deleted policy branch of WorkspaceJoinUserPage so the user is returned to the chat they came from (or to the Inbox) instead of being cross-navigated into the stale Workspaces tab. This is the minimal, root-cause fix and avoids the entire downstream WORKSPACE_INITIAL → latched-NotFound trap.

src/pages/workspace/WorkspaceJoinUserPage.tsx#L29-L48:

 useEffect(() => {
     if (isUnmounted.current || isPolicyLoading) {
         return;
     }
     if (!isEmptyObject(policy) && !policy?.isJoinRequestPending && !isPendingDeletePolicy(policy)) {
         Navigation.isNavigationReady().then(() => {
             Navigation.goBack();
             Navigation.navigate(ROUTES.WORKSPACE_INITIAL.getRoute(policyID));
         });
         return;
     }
+    // The invite link points to a policy that is gone (deleted) or is being deleted.
+    // Skip the join request — the backend will reject it — and return the user to where
+    // they came from. Routing them to WORKSPACES_LIST instead would cross-tab navigate
+    // into a stale Workspaces stack that still holds WORKSPACE.INITIAL for the deleted
+    // policyID, which then renders FullPageNotFoundView with no usable back button on wide web.
+    if (isEmptyObject(policy) || isPendingDeletePolicy(policy)) {
+        Navigation.isNavigationReady().then(() => {
+            if (isUnmounted.current) {
+                return;
+            }
+            Navigation.goBack();
+        });
+        return;
+    }
     inviteMemberToWorkspace(policyID, inviterEmail);
     Navigation.isNavigationReady().then(() => {
         if (isUnmounted.current) {
             return;
         }
         navigateAfterJoinRequest();
     });
 }, [isPolicyLoading]);

After this change:

• For a valid invite link (policy exists, user is not a member yet) → behavior unchanged: inviteMemberToWorkspace + navigateAfterJoinRequest() → Workspaces tab.
• For an already-joined policy → behavior unchanged (first branch): navigate to WORKSPACE_INITIAL.
• For a deleted / pending-delete policy → we short-circuit and pop the join page so the user is returned to the chat they tapped from. No stale WORKSPACE_INITIAL restoration, no orphan NotFound page, no missing back button.

This is the same shape of fix as #90769's regression-test target (return-to-chat from a deleted-workspace flow) and complements PR #90769's latch by removing the only path that lands on it from a chat link.

What alternative solutions did you explore? (Optional)

Alt 1 — Clear the Workspaces tab stack inside navigateAfterJoinRequest before the navigate(WORKSPACES_LIST). Dispatching popToTop against WORKSPACE_NAVIGATOR.key before the cross-tab push would discard the stale WORKSPACE.INITIAL. Rejected: navigateAfterJoinRequest is also used by the successful invite-flow (WorkspaceJoinUserPage.tsx#L40-L46) where popping the user out of an in-progress workspace stack would regress existing UX.

Alt 2 — Force shouldShowBackButton={true} and an Inbox-aware onBackButtonPress on the FullPageNotFoundView inside WorkspaceInitialPage. Treats the symptom: it puts an arrow on the stranded page but still leaves the user on a screen they shouldn't have reached, and on wide web the LHS-pane header has no slot for a useful back affordance (see RCA). Rejected as cosmetic — doesn't undo the wrong cross-tab destination.

Alt 3 — Patch goBackFromInvalidPolicy (PolicyUtils.ts#L1209) to also reset the Workspaces tab state when the deleting user is bumped out. Prevents the stale WORKSPACE.INITIAL from existing in the first place. Larger blast radius (changes the deletion path for every workspace deletion, not just the chat-link case) and doesn't help users who arrive at the URL from another device/session.

Chose the gating change in WorkspaceJoinUserPage because it fixes the actual cause (we should never invite-then-cross-tab to WORKSPACES_LIST when the policy is gone), is scoped to one effect branch, and leaves every other invite/deletion path untouched.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[lxyct825-ops]

Proposal

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

[$250] Back button is not showing on "Hmm... it's not here" page

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.