[$250] Domain - App crashes on navigating to domain settings via admin access deeplink.

[jponikarchuk]

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.61-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: #86815
Email or phone of affected tester (no customers): admin@expplause.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 10/Chrome
App Component: Workspace Settings

Action Performed:

Case 5: Domain page deeplink: https://staging.new.expensify.com/domain/21139263/members/settings

1. Open the NewDot app
2. Navigate to the Domain member setting page and copy the link
3. Send the link to any chat
4. Click on the URL: https://staging.new.expensify.com/domain/21139263/members/settings

Expected Result:

Verify the Domain Initial Page loads correctly

Actual Result:

Web page crashes
Uh-oh, something went wrong!
If the problem persists, reach out to concierge@expensify.com

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

logs.txt

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @truph01

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022046842649033514965
• Upwork Job ID: 2046842649033514965
• Last Price Increase: 2026-06-03

[MelvinBot]

Proposal

What is the root cause of that problem?

The crash is caused by route pattern ambiguity in the navigation linking config combined with domain data never loading on deeplink.

Route ambiguity: In config.ts:1347-1361, MEMBER_DETAILS (path domain/:domainAccountID/members/:accountID) is registered before MEMBERS_SETTINGS (path domain/:domainAccountID/members/settings). When React Navigation matches the URL /domain/21139263/members/settings, the wildcard :accountID in MEMBER_DETAILS can capture the literal string "settings" — routing the user to DomainMemberDetailsPage with accountID = "settings" instead of DomainMembersSettingsPage.

Data never loads: In DomainInitialPage.tsx:94-99, the API call openDomainInitialPage(domainName) only fires when domainName is truthy. On deeplink, the domain object doesn't exist in Onyx yet, so domainName is undefined and the data fetch never happens. This means the domain never loads, and DomainInitialPage.tsx:111-117 calls Navigation.goBack() because domain is falsy — crashing the navigation state during initial render.

Additionally, all domain screens lack parse functions in the linking config (unlike other screens that use parse: { index: Number }), so domainAccountID arrives as a string from URL parsing while all TypeScript types expect a number.

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

1. Reorder routes in config.ts: Move MEMBERS_SETTINGS (and other literal-segment routes like ADD_MEMBER with path .../members/invite) before MEMBER_DETAILS in the RHP navigator config so that specific paths match before the wildcard :accountID pattern.

2. Add parse functions to all domain screen configs in config.ts to convert domainAccountID (and accountID where applicable) from strings to numbers: parse: { domainAccountID: Number }.

3. Fix deeplink data loading in DomainInitialPage.tsx: Allow the initial data fetch to use domainAccountID from route params when domainName is not yet available, so domain data loads on deeplink instead of immediately navigating away.

What alternative solutions did you explore? (Optional)

An alternative would be to change the route pattern for MEMBER_DETAILS to use a prefix (e.g., domain/:domainAccountID/members/detail/:accountID) to eliminate ambiguity entirely. However, reordering is simpler and consistent with how React Navigation is designed to handle this (specific routes before wildcards).

---

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 - @truph01 (External)

[melvin-bot]

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

[wildan-m]

Proposal

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

Opening the deeplink https://staging.new.expensify.com/domain/:domainAccountID/members/settings (e.g. from a chat message) crashes the web app with the generic error-boundary screen ("Uh-oh, something went wrong!"). The attached console log shows:

TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))
at Array.from (<anonymous>)
at getPathFromState (vendors…)
at getPathFromState (main… — our wrapper)
at CardContainerInner (…)

So the exception is thrown while React Navigation is serializing the freshly-built state back to a URL during the first render of the RHP card, not while the settings page itself is rendering its UI. Because the error happens above the error boundary and the whole card is unmounted, the user never reaches the Domain members settings screen.

What is the root cause of that problem?

When the URL is parsed into a navigation state, our adapter in src/libs/Navigation/helpers/getAdaptedStateFromPath.ts recognises Members_Settings as an RHP screen and uses RHP_TO_DOMAIN to build the fullscreen context underneath the overlay:

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

Lines 172 to 189 in 215c0c8

	if (RHP_TO_DOMAIN[route.name]) {
	const paramsFromRoute = getParamsFromRoute(RHP_TO_DOMAIN[route.name]);
	const domainSplitRoute = getInitialSplitNavigatorState(
	{
	name: SCREENS.DOMAIN.INITIAL,
	params: paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : undefined,
	},
	{
	name: RHP_TO_DOMAIN[route.name],
	params: paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : undefined,
	},
	);
	return {
	name: NAVIGATORS.WORKSPACE_NAVIGATOR,
	state: getRoutesWithIndex([{name: SCREENS.WORKSPACES_LIST}, domainSplitRoute]),
	};

Two things in that block produce a state shape that getPathFromState cannot re-serialize for this particular deeplink:

1. paramsFromRoute is derived from getParamsFromRoute(RHP_TO_DOMAIN[route.name]), which resolves to the central screen (SCREENS.DOMAIN.MEMBERS), not from the RHP screen that was actually deeplinked (SCREENS.DOMAIN.MEMBERS_SETTINGS). For MEMBERS_SETTINGS the two happen to overlap on domainAccountID, but the sidebar SCREENS.DOMAIN.INITIAL route has its own :domainAccountID pattern and is given params picked from the target URL via the MEMBERS pattern — never the INITIAL pattern. This is the only DOMAIN sub-tree in the app where a path is not set on the sidebar route.

2. Unlike the RHP_TO_WORKSPACES_LIST branch a few lines above — which explicitly sets path: normalizePath(ROUTES.WORKSPACES_LIST.route) on the prepended WORKSPACES_LIST route:

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

   Lines 124 to 135 in 215c0c8

   	if (RHP_TO_WORKSPACES_LIST[route.name]) {
   	return {
   	name: NAVIGATORS.WORKSPACE_NAVIGATOR,
   	state: getRoutesWithIndex([
   	{
   	name: SCREENS.WORKSPACES_LIST,
   	// prepending a slash to ensure closing the RHP after refreshing the page
   	// replaces the whole path with "/workspaces", instead of just replacing the last url segment ("/x/y/workspaces")
   	path: normalizePath(ROUTES.WORKSPACES_LIST.route),
   	},
   	]),
   	};

   — the DOMAIN branch prepends {name: SCREENS.WORKSPACES_LIST} with no path at all:

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

   Lines 186 to 189 in 215c0c8

   	return {
   	name: NAVIGATORS.WORKSPACE_NAVIGATOR,
   	state: getRoutesWithIndex([{name: SCREENS.WORKSPACES_LIST}, domainSplitRoute]),
   	};

   When React Navigation later walks the state during getPathFromState to rebuild the URL for the freshly-mounted RHP card, it expects either a resolvable path or params matching every dynamic segment on that level's configured pattern. The WORKSPACES_LIST stub has neither, so RN falls back to a branch that calls Array.from(…) on an undefined segment list and throws.

The same code path is taken for domain/:domainAccountID/admins/settings, but in practice users reach the members area more often (and the QA case here is specifically the members deeplink), which is why it has surfaced as a crash for Case 5 of the QA pass for PR #86815.

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

Make the DOMAIN RHP branch in getAdaptedStateFromPath produce a state that is safe for getPathFromState to re-serialize, mirroring the WORKSPACES_LIST branch that already does this correctly:

1. In the RHP_TO_DOMAIN[route.name] block (src/libs/Navigation/helpers/getAdaptedStateFromPath.ts:172-189), set an explicit path on the prepended WORKSPACES_LIST stub so the root of the Workspace navigator is serializable even before any domain data loads — same fix shape as the RHP_TO_WORKSPACES_LIST branch. This removes the undefined state that Array.from is invoked on.

2. Derive paramsFromRoute from the sidebar screen's own pattern (SCREENS.DOMAIN.INITIAL) when building the sidebar route, and from the central screen's pattern (RHP_TO_DOMAIN[route.name]) when building the central route, instead of reusing one list for both. For MEMBERS_SETTINGS the result is unchanged, but it hardens the flow for future sub-pages (e.g. anything that might pick up an accountID or other extra params that do not apply to DOMAIN.INITIAL).

3. Regression-test by deeplinking each DOMAIN RHP route — at minimum domain/:id/members/settings, domain/:id/admins/settings, domain/:id/members/settings/two-factor-auth, and domain/:id/members/invite — from a logged-in session as well as a cold-start / fresh tab. All should render the matching RHP screen (or the NotFound fallback via DomainNotFoundPageWrapper when the account is not an admin), never the generic error boundary.

Once this is in, the matching path serialization succeeds, CardContainerInner finishes its first render, and the page falls through to the existing BaseDomainSettingsPage → DomainNotFoundPageWrapper guards, which already handle the "domain data not yet loaded / user is not an admin" cases correctly:

App/src/pages/domain/DomainNotFoundPageWrapper.tsx

Lines 29 to 72 in 215c0c8

	function DomainNotFoundPageWrapper({domainAccountID, shouldBeBlocked, fullPageNotFoundViewProps, ...props}: DomainNotFoundPageWrapperProps) {
	const [domain, domainMetadata] = useOnyx(`${ONYXKEYS.COLLECTION.DOMAIN}${domainAccountID}`);
	const [adminAccountIDs] = useOnyx(`${ONYXKEYS.COLLECTION.DOMAIN}${domainAccountID}`, {
	selector: adminAccountIDsSelector,
	});
	const {accountID: currentUserAccountID} = useCurrentUserPersonalDetails();
	const isAdmin = adminAccountIDs?.includes(currentUserAccountID);
	const shouldShowFullScreenLoadingIndicator = isLoadingOnyxValue(domainMetadata);
	const shouldShowNotFoundPage = !domain || !isAdmin || shouldBeBlocked;
	useEffect(() => {
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	if (shouldShowFullScreenLoadingIndicator || (domain && isAdmin)) {
	return;
	}
	Navigation.dismissModal();
	}, [domain, isAdmin, shouldShowFullScreenLoadingIndicator]);
	if (shouldShowFullScreenLoadingIndicator) {
	const reasonAttributes: SkeletonSpanReasonAttributes = {
	context: 'DomainNotFoundPageWrapper',
	shouldShowFullScreenLoadingIndicator,
	};
	return <FullscreenLoadingIndicator reasonAttributes={reasonAttributes} />;
	}
	if (shouldShowNotFoundPage) {
	return (
	<NotFoundPage
	shouldForceFullScreen
	shouldShowOfflineIndicator={false}
	onBackButtonPress={() => {
	Navigation.goBack(ROUTES.WORKSPACES_LIST.route);
	}}
	// eslint-disable-next-line react/jsx-props-no-spreading
	{...fullPageNotFoundViewProps}
	shouldShowBackButton
	/>
	);
	}
	return props.children;

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88506-domain-deeplink-crash?expand=1

What alternative solutions did you explore? (Optional)

• Registering MEMBERS_SETTINGS before MEMBER_DETAILS in src/libs/Navigation/linkingConfig/config.ts so that members/settings wins path matching over members/:accountID. React Navigation already prioritises static segments over dynamic ones for matching, so this is not the cause of the crash (the crash is in path generation, not path matching); reordering would be cosmetic at best and would not affect the Array.from(undefined) throw.
• Wrapping CardContainerInner's render in a local try/catch that falls back to route.path when getPathFromState fails. This would hide the symptom but leaves the malformed state in place, and subsequent reads of the same state (browser history sync, Navigation.getCurrentRoute(), etc.) would still produce inconsistent URLs.

[aswin-s]

Proposal

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

When opening a domain member settings page directly from a deeplink such as /domain/21139263/members/settings, it causes the app to crash with the generic error page, which prevents the domain initial page from loading correctly.

What is the root cause of that problem?

PR #86815 introduced adminAccountIDsSelector in src/selectors/Domain.ts to replace the sharedNVP_private_admin_access_* Onyx key. The null guard in that function returns a bare [] literal when the domain Onyx entry is not loaded yet:

App/src/selectors/Domain.ts

Lines 41 to 44 in 215c0c8

	function adminAccountIDsSelector(domain: OnyxEntry<Domain>): number[] {
	if (!domain) {
	return [];
	}

src/pages/domain/DomainNotFoundPageWrapper.tsx subscribes to the domain key with useOnyx and passes adminAccountIDsSelector as the selector. On a cold deeplink, the domain key is initially unavailable during hydration, so the selector runs while domain is undefined. Because return [] creates a new array reference each time, the selected snapshot is not referentially stable while the underlying store value has not changed. React detects this unstable snapshot and throws The result of getSnapshot should be cached to avoid an infinite loop, which is caught by the error boundary and crashes the page.

This path is less likely during in-app navigation because the domain data is already present in Onyx before DomainNotFoundPageWrapper mounts.

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

1. src/selectors/Domain.ts - In adminAccountIDsSelector, replace the return []; null-domain guard with return getEmptyArray<number>();.

What alternative solutions did you explore? (Optional)

Memoizing the selector result at the DomainNotFoundPageWrapper call site would only protect that one consumer. adminAccountIDsSelector is reused by other domain pages, so fixing the selector itself is the correct single source of truth and matches the stable empty-array pattern already used by memberAccountIDsSelector.

[wildan-m]

Proposal updated — added compare branch with implementation.

[teooet1973-hue]

The crash has platform-specific causes that require three independent fixes:

Web: getAdaptedStateFromPath.ts builds the RHP_TO_DOMAIN branch without
setting an explicit path on the prepended WORKSPACES_LIST stub. When React
Navigation calls getPathFromState() to serialize the state back to a URL on
first render, it hits Array.from(undefined) and throws — crashing before the
page renders.

Native (iOS/Android): React Navigation evaluates routes in registration order
on native. MEMBER_DETAILS (domain/:domainAccountID/members/:accountID) is
registered before MEMBERS_SETTINGS, so the wildcard :accountID captures the
literal "settings" string. DomainMemberDetailsPage then receives
accountID="settings" — an invalid value — and crashes.

Both platforms: adminAccountIDsSelector in Domain.ts returns a bare [] literal
when domain is not yet loaded in Onyx. This creates a new array reference on
every call, causing React's getSnapshot consistency check to throw "The result
of getSnapshot should be cached to avoid an infinite loop" — which the error
boundary catches and surfaces as the crash screen.

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

1. getAdaptedStateFromPath.ts — in the RHP_TO_DOMAIN block, set path:
   normalizePath(ROUTES.WORKSPACES_LIST.route) on the prepended WORKSPACES_LIST
   stub, mirroring the RHP_TO_WORKSPACES_LIST branch. Fixes the web serialization
   crash.
2. config.ts — move MEMBERS_SETTINGS before MEMBER_DETAILS in the RHP
   navigator config so the literal settings segment matches before the wildcard
   :accountID. Fixes the native route matching crash.
3. Domain.ts — replace return [] in adminAccountIDsSelector with return
   getEmptyArray() to return a stable reference. Fixes the unstable
   snapshot crash on both platforms.

What alternative solutions did you explore? (Optional)

Applying only fixes 1 or 2 in isolation leaves the other platform broken.
Applying only fix 3 without fixes 1 and 2 resolves the selector crash but the
page still never renders correctly. All three are needed together for a clean
fix across Android, iOS, and Web.

[melvin-bot]

📣 @teooet1973-hue! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>