[Due for payment 2026-05-28] [$250] 88633R2 - Domain - Not here page appears after resetting the domain

[unzig21]

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.64-23
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/TR-23129/folder/31025987/72286550/1372516196?sort=-identifier
Email or phone of affected tester (no customers): admin@expplause.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11 / Chrome, iPhone 13 / iOS 26.5, Samsung Galaxy A52 / Android 14
App Component: Other

Action Performed:

Preconditions:

• Logged in to admin@expplause.com

Steps:

1. Navigate to workspace
2. Click the expplause.com domain
3. Click Domain admins
4. Click "reset domain"
5. Enter "expplause.com" on domain name field and click "reset domain"

Expected Result:

User lands back to workspace page after resetting the domain

Actual Result:

Not here page appears after resetting the domain

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7141861_1777542105720.domain__1_.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049794401741844689
• Upwork Job ID: 2049794401741844689
• Last Price Increase: 2026-04-30

[MelvinBot]

Proposal

Root Cause:

When resetDomain() is called from DomainResetPage.tsx:60, it optimistically sets the domain Onyx data to null (Domain.ts:777-779) before Navigation.goBack() on line 61 completes.

DomainInitialPage is a persistent screen (always mounted as the sidebar in DomainSplitNavigator.tsx:29). When the domain goes null, it immediately re-renders FullPageNotFoundView with shouldShow={!domain || !isAdmin} — displaying "Hmm... it's not here" before navigation away finishes.

A useEffect in DomainInitialPage.tsx:109-115 also tries to goBack when domain becomes falsy, but the synchronous render of FullPageNotFoundView wins the race against the asynchronous effect.

Solution:

In DomainResetPage.tsx, call Navigation.goBack(ROUTES.WORKSPACES_LIST.route) before resetDomain() so the user navigates away before the optimistic Onyx update nullifies the domain data and triggers the NotFound view on the persistent DomainInitialPage.

 const handleResetDomain = () => {
     if (isSubmitDisabled) { ... }
+    Navigation.goBack(ROUTES.WORKSPACES_LIST.route);
     resetDomain(route.params.domainAccountID, domainName, domain);
-    Navigation.goBack(ROUTES.WORKSPACES_LIST.route);
 };

Investigation details

Data flow causing the bug:

1. User is on DomainResetPage (RHP) at route domain/:domainAccountID/admins/:accountID/reset-domain
2. User submits the reset form → handleResetDomain() fires
3. resetDomain() optimistically merges domain to null via Onyx — this is synchronous
4. DomainInitialPage (persistent sidebar, always mounted) re-renders: !domain is now true
5. FullPageNotFoundView renders with shouldShow=true → user sees "Not here" page
6. Navigation.goBack() from both DomainResetPage and DomainInitialPage's useEffect fire, but too late — the NotFound view already rendered

Alternative explanations considered:

• Navigation itself could be failing — unlikely since the useEffect in DomainInitialPage also calls goBack as a fallback and users do eventually leave the page
• The API could be failing and leaving the user stranded — unlikely since the issue is about the NotFound page flashing, not a permanent state, and the optimistic update is the trigger

Confidence: High — both researchers independently confirmed the same race condition with specific file:line evidence.

Related issues: Several other "Not here" page issues follow similar patterns where optimistic deletion triggers NotFound before navigation completes:

• Expensify/App#83995 — Not here page after toggling keep me as admin and creating workspace
• Expensify/App#85478 — Not here page after clicking "Pay via workspace" and navigating back

---

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.

[melvin-bot]

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

[MobileMage]

Proposal

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

After a user resets a domain, the "Not here" (404) page is briefly shown before — or instead of — landing on the workspaces list page.

What is the root cause of that problem?

The problem is a race condition between two concurrent navigation actions triggered by the domain reset. In DomainResetPage.handleResetDomain, the code calls resetDomain(...) first and then immediately calls Navigation.goBack(ROUTES.WORKSPACES_LIST.route). The resetDomain action applies an optimistic update that sets the domain's Onyx entry to null synchronously. This triggers a re-render of DomainInitialPage, which is still mounted in the navigator stack. Its useEffect (line 109–115) evaluates domain as falsy and shouldShowFullScreenLoadingIndicator as false, so it also calls Navigation.goBack(ROUTES.WORKSPACES_LIST.route). Meanwhile, the FullPageNotFoundView in DomainInitialPage with shouldShow={!domain || !isAdmin} immediately becomes true and renders the "Not here" page because the domain was nullified. The result is that the user sees the not-found screen during the brief window between the optimistic update and the navigation completing.

App/src/pages/domain/DomainResetPage.tsx

Lines 55 to 62 in 680b88f

	const handleResetDomain = () => {
	if (isSubmitDisabled) {
	Log.hmmm('Domain data is missing or there are more than 1 admin left');
	return;
	}
	resetDomain(route.params.domainAccountID, domainName, domain);
	Navigation.goBack(ROUTES.WORKSPACES_LIST.route);
	};

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

In DomainResetPage, the navigation should happen before calling resetDomain, not after. Swapping the order so that Navigation.navigate(ROUTES.WORKSPACES_LIST.route) (using navigate rather than goBack, since goBack depends on stack history) fires first takes the user off the domain screens before the optimistic Onyx update nullifies the domain data. This prevents DomainInitialPage from ever rendering the not-found state in response to the reset, since the page is no longer active in the foreground when the data changes.

Additionally, DomainInitialPage's redirect useEffect should also check whether the domain has a pending delete action (CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE on DOMAIN_PENDING_ACTIONS) and skip the goBack call in that case, so that even if the screen is still briefly in the navigator stack during a reset it does not redundantly fire a competing navigation. This guards against similar timing issues in other flows that might delete the domain.

App/src/pages/domain/DomainInitialPage.tsx

Lines 109 to 115 in 680b88f

	useEffect(() => {
	if (shouldShowFullScreenLoadingIndicator || (domain && isAdmin)) {
	return;
	}
	Navigation.goBack(ROUTES.WORKSPACES_LIST.route);
	}, [domain, isAdmin, shouldShowFullScreenLoadingIndicator]);

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

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

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[aswin-s]

🚨 Edited by proposal-police: This proposal was edited at 2026-04-30 10:20:12 UTC.

Proposal

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

When the only domain admin resets a domain, the app briefly navigates back into the deleted domain flow and shows a Not here page instead of returning to the workspaces list.

What is the root cause of that problem?

The regression is in src/pages/domain/DomainResetPage.tsx, in the access guard that was added to prevent opening the reset page when a domain has multiple admins.

DomainResetDomainPage uses this effect:

useEffect(() => {
    if (isLoadingDomain || domainHasOnlyOneAdmin) {
        return;
    }
    Navigation.goBack(ROUTES.DOMAIN_ADMIN_DETAILS.getRoute(domainAccountID, accountID));
}, [accountID, domainAccountID, domainHasOnlyOneAdmin, isLoadingDomain]);

That guard uses domainHasOnlyOneAdmin, which is derived from adminAccountIDsSelector(domain). In src/selectors/Domain.ts, adminAccountIDsSelector() returns [] when domain is null.

During resetDomain() in src/libs/actions/Domain.ts, the optimistic update immediately sets DOMAIN.${domainAccountID} to null. As soon as that happens:

1. adminAccountIDsSelector(null) returns []
2. domainHasOnlyOneAdmin flips to false
3. The effect treats the page as an invalid multi-admin state and calls Navigation.goBack(ROUTES.DOMAIN_ADMIN_DETAILS.getRoute(...))

That sends the user back to DomainAdminDetailsPage, which renders through BaseDomainMemberDetailsComponent into DomainNotFoundPageWrapper. Since the domain was just deleted, DomainNotFoundPageWrapper evaluates !domain as true and shows the Not here page.

So the deepest root cause is not the reset action itself. The problem is that the reset-page guard uses admin-count state as a proxy for access validity and does not distinguish between these two different cases:

• the domain still exists and now has multiple admins
• the domain has been deleted by the reset flow

Those states must not be handled the same way.

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

Update the useEffect guard in src/pages/domain/DomainResetPage.tsx so it only redirects to DOMAIN_ADMIN_DETAILS when the domain still exists and the page has become invalid because there are now multiple admins.

Concretely:

1. Change the effect guard to return early when domain is null
2. Add domain to the dependency array because the redirect condition now depends on it
3. Leave handleResetDomain() as-is; its existing Navigation.goBack(ROUTES.WORKSPACES_LIST.route) is already the correct navigation after a successful reset

The redirect condition should effectively become:

if (isLoadingDomain || !domain || domainHasOnlyOneAdmin) {
    return;
}

This is also consistent with the existing pattern in src/pages/domain/DomainInitialPage.tsx, which distinguishes a missing domain from a valid-but-inaccessible domain instead of routing deeper into deleted-domain screens.

What alternative solutions did you explore? (Optional)

• Changing handleResetDomain() to use a different navigation call was rejected because the submit handler is already correct; the regression is the access guard firing after the optimistic delete.
• Removing the effect entirely was rejected because it would re-open the original problem that the guard was added to solve: the reset page remaining accessible when the domain has more than one admin.

[github-actions]

⚠️ @KJ21-ENG Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[mukhrr]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.