[Due for payment 2026-07-21] [$250] Workspace - Pending join request workspace doesn't show the owner details

[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.4.19-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93293
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, iPhone 13 / iOS 26.5, Samsung Galaxy A52 / Android 14
App Component: Workspace Settings

Action Performed:

Preconditions:
login with an account that own workspace

Steps:

1. Join to a workspace by deeplink to trigger a pending join request workspace (can use this link: https://staging.new.expensify.com/workspaces/F6BEDB88EA6D8E4D/join?email=piyootest+ba2@gmail.com)
2. Navigate to workspace tab and observe the workspace that has pending join request badge

Expected Result:

Owner details should be shown in the pending join request workspace

Actual Result:

Owner details is not shown on pending join request workspace

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7190538_1782360912731.pendinb_join_req.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070049338974512618
• Upwork Job ID: 2070049338974512618
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @marufsharifi

[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/4d056f2dbcfd45b769119def46ceb4c4e559069a2b3d8af14067a77701323cf2

[MelvinBot]

Proposal

What is the root cause of that problem?

For a pending join request workspace, the owner is the owner of a workspace you are not yet a member of — so that person is typically not present in your local PERSONAL_DETAILS_LIST.

The Workspaces list derives the owner avatar/name only from PERSONAL_DETAILS_LIST[ownerAccountID]. When that entry is missing (the common case for a stranger‑owned workspace), the lookup returns undefined and the owner avatar + name render blank — even though the owner's email is already available in policyDetailsForNonMembers.ownerEmail and is never used as a fallback.

Evidence (file:line)

• Pending‑join row builds owner fields from a PERSONAL_DETAILS_LIST lookup keyed by ownerAccountID; there is no fallback when the entry is missing — WorkspacesListPage.tsx:96-115 (the lookup at line 98).
• ownerDisplayDetails is a narrow projection of PERSONAL_DETAILS_LIST; an accountID that isn't in the list is simply skipped — selectors/PersonalDetails.ts:26-38.
• The list policy projection keeps ownerAccountID but drops ownerEmail from policyDetailsForNonMembers — selectors/Policy.ts:100-109.
• policyDetailsForNonMembers does carry ownerEmail (and ownerAccountID) — types/onyx/Policy.ts:1936-1951.
• The row renders the owner avatar from item.ownerAvatar and the name from item.ownerName only — WorkspaceTableRow.tsx:189-200.

On PR #93293: this bug was surfaced during that PR's QA (its test step 7 checks owner details on a pending‑join row). I compared the owner‑derivation logic before/after #93293 and it is functionally identical, so the missing‑owner behavior most likely pre‑dates #93293 rather than being introduced by it. The fix below is in Expensify/App and holds either way.

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

Make the pending‑join row fall back to the data already present in policyDetailsForNonMembers when the owner isn't in PERSONAL_DETAILS_LIST:

1. Include ownerEmail in the nonMemberDetails projection in createWorkspaceListPoliciesSelector (selectors/Policy.ts:100-109).
2. In the pending‑join branch of WorkspacesListPage (WorkspacesListPage.tsx:96-120), when ownerDetails is missing, set ownerLogin/ownerName from nonMemberDetails.ownerEmail so the owner email is shown as a minimum.

This guarantees the owner column is populated for pending‑join rows regardless of whether the owner's personal details have been loaded.

What alternative solutions did you explore? (Optional)

If the owner is in fact expected to be loaded into PERSONAL_DETAILS_LIST during the join flow, the alternative is to confirm with logs whether PERSONAL_DETAILS_LIST[ownerAccountID] is actually populated for a reproducing pending‑join workspace. If it is, the issue is a reactivity gap from the narrowed subscriptions in #93293 instead; if it isn't, the fallback fix above is the correct path. The fallback is the more robust option either way.

---

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

[MobileMage]

Proposal

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

On the Workspaces tab, a workspace that the current user has a pending join request for shows its name, type, and the "Requested" badge, but the owner column is blank — the owner's name, email and avatar are not rendered. Every other (member) workspace shows its owner correctly. This is reproducible on staging and production across all native and web platforms.

What is the root cause of that problem?

The owner column is populated in WorkspacesListPage from a single source: ownerDisplayDetails, which is a narrow subscription to ONYXKEYS.PERSONAL_DETAILS_LIST keyed by ownerAccountID. For a pending-join workspace the code resolves the owner the exact same way it does for a member workspace — it looks the owner up by account ID in the current user's personal-details list:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 96 to 116 in cda43db

	if (policy.isJoinRequestPending && policy.nonMemberDetails) {
	const {policyID, ownerAccountID} = policy.nonMemberDetails;
	const ownerDetails = ownerAccountID ? ownerDisplayDetails?.[ownerAccountID] : undefined;
	const pendingWorkspaceRow: WorkspaceRowData = {
	keyForList: policyID,
	policyID,
	disabled: true,
	errors: undefined,
	type: policy.nonMemberDetails.type,
	title: policy.nonMemberDetails.name,
	role: CONST.POLICY.ROLE.USER,
	isDeleted: false,
	isJoinRequestPending: true,
	isDefault: activePolicyID === policyID,
	shouldAnimateInHighlight: duplicateWorkspace?.policyID === policyID,
	ownerAccountID,
	ownerLogin: ownerDetails ? ownerDetails.login : undefined,
	ownerAvatar: ownerDetails ? ownerDetails.avatar : undefined,
	ownerName: ownerDetails ? getDisplayNameOrDefault(ownerDetails) : undefined,
	iconType: policy.nonMemberDetails.avatar ? CONST.ICON_TYPE_AVATAR : CONST.ICON_TYPE_ICON,

The problem is that the owner of a pending-join workspace is a non-member relative to the current user. Their displayName/login/avatar are not present in PERSONAL_DETAILS_LIST (we only have personal details for people we share reports/workspaces with). So const ownerDetails = ownerAccountID ? ownerDisplayDetails?.[ownerAccountID] : undefined; returns undefined, and consequently ownerLogin, ownerName and ownerAvatar are all left undefined. WorkspaceTableRow then renders item.ownerName ?? '' (an empty owner cell) and an empty Avatar. The data the page needs to fill the column does exist, but it lives in a different place: policy.policyDetailsForNonMembers[policyID], which the backend populates for exactly this scenario and which carries name, type, ownerAccountID, ownerEmail, and avatar (see the PolicyDetailsForNonMembers type in src/types/onyx/Policy.ts#L1936-L1951).

The new flat projection introduced in PR #93293, createWorkspaceListPoliciesSelector, copies most of policyDetailsForNonMembers into nonMemberDetails but deliberately drops ownerEmail:

nonMemberDetails = {policyID: nonMemberPolicyID, name: details.name, type: details.type, ownerAccountID: details.ownerAccountID, avatar: details.avatar};

App/src/selectors/Policy.ts

Lines 103 to 109 in cda43db

	nonMemberDetails = {
	policyID: nonMemberPolicyID,
	name: details.name,
	type: details.type,
	ownerAccountID: details.ownerAccountID,
	avatar: details.avatar,
	};

So even the one reliable owner identifier we have (ownerEmail) never reaches the page. Note this is a pre-existing bug, not a regression from #93293 — the pre-refactor page resolved the pending owner identically (ownerDisplayDetails?.[policyInfo.ownerAccountID]) and would have had the same empty column; #93293's QA simply surfaced it. The fix therefore belongs at the page/selector layer where the row is composed, not in the personal-details data.

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

For pending-join rows we should stop relying on PERSONAL_DETAILS_LIST and instead use the owner data we already have in nonMemberDetails. First, keep ownerEmail in the selector projection (add it to the nonMemberDetails Pick type at src/selectors/Policy.ts#L80 and to the object built at lines 103-109). Then in the pending branch of WorkspacesListPage, fall back to nonMemberDetails when the owner isn't in personal details — getDisplayNameOrDefault already returns login when no displayName exists, so passing the email through it renders the owner email as the name:

const ownerDetails = ownerAccountID ? ownerDisplayDetails?.[ownerAccountID] : undefined;
const ownerLogin = ownerDetails?.login ?? policy.nonMemberDetails.ownerEmail;
const ownerName = ownerDetails ? getDisplayNameOrDefault(ownerDetails) : ownerLogin;
const ownerAvatar = ownerDetails?.avatar; // optional: keep falling back to default user avatar

This is safe and scoped: it only changes the policy.isJoinRequestPending && policy.nonMemberDetails branch, so member workspaces are untouched and continue to resolve through personal details exactly as before. The data is guaranteed available because the branch is only entered when policyDetailsForNonMembers exists, and ownerEmail is a required field of that record. It also matches the existing pattern for the workspace avatar, which already reads from nonMemberDetails.avatar rather than personal details.

What alternative solutions did you explore? (Optional)

We could instead seed the non-member owner into PERSONAL_DETAILS_LIST (an optimistic personal-detail entry) when policyDetailsForNonMembers arrives, so the existing account-ID lookup just works. We rejected this because it mutates shared global personal-details state for someone the user has no real relationship with, risks leaking a partial/optimistic profile into other surfaces, and is far more invasive than reading the owner email we already store on the policy.

[lorretheboy]

Proposal

What is the root cause of that problem?

After the WorkspacesListPage refactor, each row's owner name/avatar/login is resolved only from PERSONAL_DETAILS_LIST, via the ownerDisplayDetails[ownerAccountID] lookup the page builds here:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 73 to 80 in cda43db

	const ownerAccountIDs = [
	...new Set(
	(workspaceListPolicies ?? [])
	.map((policy) => (policy.isJoinRequestPending && policy.nonMemberDetails ? policy.nonMemberDetails.ownerAccountID : policy.ownerAccountID))
	.filter((id): id is number => id !== undefined),
	),
	];
	const [ownerDisplayDetails] = useOnyx(ONYXKEYS.PERSONAL_DETAILS_LIST, {selector: createDisplayDetailsByAccountIDsSelector(ownerAccountIDs)}, [workspaceListPolicies]);

For a pending join-request workspace you are only a non-member of, the owner's personal-details record is not loaded on the client, so ownerDisplayDetails[ownerAccountID] is undefined. In the pending branch that makes ownerName, ownerAvatar and ownerLogin all undefined, so the owner column renders blank:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 96 to 116 in cda43db

	if (policy.isJoinRequestPending && policy.nonMemberDetails) {
	const {policyID, ownerAccountID} = policy.nonMemberDetails;
	const ownerDetails = ownerAccountID ? ownerDisplayDetails?.[ownerAccountID] : undefined;
	const pendingWorkspaceRow: WorkspaceRowData = {
	keyForList: policyID,
	policyID,
	disabled: true,
	errors: undefined,
	type: policy.nonMemberDetails.type,
	title: policy.nonMemberDetails.name,
	role: CONST.POLICY.ROLE.USER,
	isDeleted: false,
	isJoinRequestPending: true,
	isDefault: activePolicyID === policyID,
	shouldAnimateInHighlight: duplicateWorkspace?.policyID === policyID,
	ownerAccountID,
	ownerLogin: ownerDetails ? ownerDetails.login : undefined,
	ownerAvatar: ownerDetails ? ownerDetails.avatar : undefined,
	ownerName: ownerDetails ? getDisplayNameOrDefault(ownerDetails) : undefined,
	iconType: policy.nonMemberDetails.avatar ? CONST.ICON_TYPE_AVATAR : CONST.ICON_TYPE_ICON,

The only owner identity the client actually holds for a non-member lives in policyDetailsForNonMembers, which carries ownerEmail. But createWorkspaceListPoliciesSelector projects only name/type/ownerAccountID/avatar and drops ownerEmail, so there is nothing to fall back to:

App/src/selectors/Policy.ts

Lines 99 to 110 in cda43db

	if (isJoinRequestPending) {
	const nonMemberEntry = Object.entries(policy.policyDetailsForNonMembers ?? {}).at(0);
	if (nonMemberEntry) {
	const [nonMemberPolicyID, details] = nonMemberEntry;
	nonMemberDetails = {
	policyID: nonMemberPolicyID,
	name: details.name,
	type: details.type,
	ownerAccountID: details.ownerAccountID,
	avatar: details.avatar,
	};
	}

So: owner is a non-member → no personal-details record → ownerDisplayDetails lookup is empty → and the one available value (ownerEmail) is dropped by the selector → owner column is empty.

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

1. Keep ownerEmail in the non-member projection — add it to the nonMemberDetails Pick type and to the object built here:

App/src/selectors/Policy.ts

Lines 79 to 110 in cda43db

	/** Projection of policyDetailsForNonMembers for join-request-pending policies */
	nonMemberDetails?: Pick<PolicyDetailsForNonMembers, 'name' | 'type' | 'ownerAccountID' | 'avatar'> & {policyID: string};
	};
	/**
	* Creates a selector returning a light, flat projection of the policies shown on the workspaces list,
	* so the page doesn't re-render when deep, frequently mutated policy fields change (isLoading* flags,
	* employeeList, customUnits, connections, etc.).
	*/
	const createWorkspaceListPoliciesSelector =
	(currentUserLogin: string | undefined) =>
	(policies: OnyxCollection<Policy>): WorkspaceListPolicy[] => {
	const result: WorkspaceListPolicy[] = [];
	for (const policy of Object.values(policies ?? {})) {
	if (!policy || !shouldShowPolicy(policy, true, currentUserLogin)) {
	continue;
	}
	const isJoinRequestPending = !!policy.isJoinRequestPending && !!policy.policyDetailsForNonMembers;
	let nonMemberDetails: WorkspaceListPolicy['nonMemberDetails'];
	if (isJoinRequestPending) {
	const nonMemberEntry = Object.entries(policy.policyDetailsForNonMembers ?? {}).at(0);
	if (nonMemberEntry) {
	const [nonMemberPolicyID, details] = nonMemberEntry;
	nonMemberDetails = {
	policyID: nonMemberPolicyID,
	name: details.name,
	type: details.type,
	ownerAccountID: details.ownerAccountID,
	avatar: details.avatar,
	};
	}

2. In the pending branch of the page, when ownerDisplayDetails[ownerAccountID] is missing, fall back to nonMemberDetails.ownerEmail for ownerName/ownerLogin (and let the avatar fall back to the default user avatar) so the owner is shown:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 96 to 116 in cda43db

	if (policy.isJoinRequestPending && policy.nonMemberDetails) {
	const {policyID, ownerAccountID} = policy.nonMemberDetails;
	const ownerDetails = ownerAccountID ? ownerDisplayDetails?.[ownerAccountID] : undefined;
	const pendingWorkspaceRow: WorkspaceRowData = {
	keyForList: policyID,
	policyID,
	disabled: true,
	errors: undefined,
	type: policy.nonMemberDetails.type,
	title: policy.nonMemberDetails.name,
	role: CONST.POLICY.ROLE.USER,
	isDeleted: false,
	isJoinRequestPending: true,
	isDefault: activePolicyID === policyID,
	shouldAnimateInHighlight: duplicateWorkspace?.policyID === policyID,
	ownerAccountID,
	ownerLogin: ownerDetails ? ownerDetails.login : undefined,
	ownerAvatar: ownerDetails ? ownerDetails.avatar : undefined,
	ownerName: ownerDetails ? getDisplayNameOrDefault(ownerDetails) : undefined,
	iconType: policy.nonMemberDetails.avatar ? CONST.ICON_TYPE_AVATAR : CONST.ICON_TYPE_ICON,

This way the row prefers the full personal details when present and otherwise shows the owner email that the backend already provides for non-members.

What alternative solutions did you explore? (Optional)

Build the pending row's owner fields directly from policyDetailsForNonMembers (email + workspace-level data) instead of routing non-member owners through the PERSONAL_DETAILS_LIST selector at all, since that list is not a reliable source for owners you don't share membership with.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

For a workspace you have a pending join request on, you are a non-member of that policy, so the workspace owner's account is not present in your PERSONAL_DETAILS_LIST Onyx store. But the owner name/avatar column is computed exclusively from that store.

In WorkspacesListPage, the owner account IDs are collected and then resolved against PERSONAL_DETAILS_LIST via createDisplayDetailsByAccountIDsSelector:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 73 to 80 in ab92615

	const ownerAccountIDs = [
	...new Set(
	(workspaceListPolicies ?? [])
	.map((policy) => (policy.isJoinRequestPending && policy.nonMemberDetails ? policy.nonMemberDetails.ownerAccountID : policy.ownerAccountID))
	.filter((id): id is number => id !== undefined),
	),
	];
	const [ownerDisplayDetails] = useOnyx(ONYXKEYS.PERSONAL_DETAILS_LIST, {selector: createDisplayDetailsByAccountIDsSelector(ownerAccountIDs)}, [workspaceListPolicies]);

That selector returns details only for accounts that already exist in the list, otherwise it skips them:

App/src/selectors/PersonalDetails.ts

Lines 26 to 38 in ab92615

	const createDisplayDetailsByAccountIDsSelector =
	(accountIDs: number[]) =>
	(personalDetailsList: OnyxEntry<PersonalDetailsList>): Record<number, DisplayDetails> => {
	const result: Record<number, DisplayDetails> = {};
	for (const accountID of accountIDs) {
	const detail = personalDetailsList?.[accountID];
	if (!detail) {
	continue;
	}
	result[accountID] = {accountID: detail.accountID, displayName: detail.displayName, login: detail.login, avatar: detail.avatar};
	}
	return result;
	};

For the pending-join row, the owner is then looked up the same way, and ownerLogin / ownerAvatar / ownerName are all left undefined when the lookup misses (which it always does for a non-member owner):

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 96 to 117 in ab92615

	if (policy.isJoinRequestPending && policy.nonMemberDetails) {
	const {policyID, ownerAccountID} = policy.nonMemberDetails;
	const ownerDetails = ownerAccountID ? ownerDisplayDetails?.[ownerAccountID] : undefined;
	const pendingWorkspaceRow: WorkspaceRowData = {
	keyForList: policyID,
	policyID,
	disabled: true,
	errors: undefined,
	type: policy.nonMemberDetails.type,
	title: policy.nonMemberDetails.name,
	role: CONST.POLICY.ROLE.USER,
	isDeleted: false,
	isJoinRequestPending: true,
	isDefault: activePolicyID === policyID,
	shouldAnimateInHighlight: duplicateWorkspace?.policyID === policyID,
	ownerAccountID,
	ownerLogin: ownerDetails ? ownerDetails.login : undefined,
	ownerAvatar: ownerDetails ? ownerDetails.avatar : undefined,
	ownerName: ownerDetails ? getDisplayNameOrDefault(ownerDetails) : undefined,
	iconType: policy.nonMemberDetails.avatar ? CONST.ICON_TYPE_AVATAR : CONST.ICON_TYPE_ICON,
	icon: policy.nonMemberDetails.avatar ? policy.nonMemberDetails.avatar : getDefaultWorkspaceAvatar(policy.name),

So in the row, formattedOwnerName resolves to '' and the owner column renders empty:

App/src/components/Tables/WorkspaceListTable/WorkspaceTableRow.tsx

Lines 189 to 199 in ab92615

	<View style={[styles.flex1, styles.flexRow, styles.gap2, styles.alignItemsCenter]}>
	<Avatar
	source={item.ownerAvatar}
	avatarID={item.ownerAccountID}
	type={CONST.ICON_TYPE_AVATAR}
	size={CONST.AVATAR_SIZE.MID_SUBSCRIPT}
	/>
	<WorkspacesListRowDisplayName
	isDeleted={item.isDeleted}
	ownerName={formattedOwnerName}
	/>

The key point: the backend already ships the owner identity for these non-member policies inside policy.policyDetailsForNonMembers[...] — the type carries ownerEmail (and ownerAccountID):

App/src/types/onyx/Policy.ts

Lines 1936 to 1951 in ab92615

	type PolicyDetailsForNonMembers = {
	/** Name of the policy */
	name: string;
	/** Policy owner account ID */
	ownerAccountID: number;
	/** Policy owner e-mail */
	ownerEmail: string;
	/** Policy type */
	type: ValueOf<typeof CONST.POLICY.TYPE>;
	/** Policy avatar */
	avatar?: string;
	};

…but createWorkspaceListPoliciesSelector drops ownerEmail when it projects nonMemberDetails, so the page never has a fallback to fall back to:

App/src/selectors/Policy.ts

Lines 98 to 111 in ab92615

	let nonMemberDetails: WorkspaceListPolicy['nonMemberDetails'];
	if (isJoinRequestPending) {
	const nonMemberEntry = Object.entries(policy.policyDetailsForNonMembers ?? {}).at(0);
	if (nonMemberEntry) {
	const [nonMemberPolicyID, details] = nonMemberEntry;
	nonMemberDetails = {
	policyID: nonMemberPolicyID,
	name: details.name,
	type: details.type,
	ownerAccountID: details.ownerAccountID,
	avatar: details.avatar,
	};
	}
	}

So: pending join → owner is a non-member → not in PERSONAL_DETAILS_LIST → createDisplayDetailsByAccountIDsSelector returns nothing for that account → ownerName/ownerLogin/ownerAvatar are undefined → empty owner column. This is all-platform and long-standing (reproducible in production), not a regression from the QA-linked PR #93293 — that PR only refactored this code and preserved the same personal-details-only lookup.

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

Use the owner email that the backend already provides on policyDetailsForNonMembers as the fallback when the owner is absent from PERSONAL_DETAILS_LIST.

1. Keep ownerEmail in the nonMemberDetails projection (it's currently stripped). Add it to the Pick<PolicyDetailsForNonMembers, …> at src/selectors/Policy.ts#L80 and carry ownerEmail: details.ownerEmail in the object built at src/selectors/Policy.ts#L103-L109.

2. In the pending-row branch of WorkspacesListPage (L96-L117), fall back to that email when ownerDetails is missing, reusing the existing getDisplayNameOrDefault already imported here — it accepts a defaultValue second argument:

App/src/libs/PersonalDetailsUtils.ts

Lines 56 to 62 in ab92615

	function getDisplayNameOrDefault(
	passedPersonalDetails?: Partial<PersonalDetails> | null,
	defaultValue = '',
	shouldFallbackToHidden = true,
	shouldAddCurrentUserPostfix = false,
	youAfterTranslation = youTranslation,
	): string {

e.g.:

ownerLogin: ownerDetails?.login ?? policy.nonMemberDetails.ownerEmail,
ownerName: getDisplayNameOrDefault(ownerDetails, policy.nonMemberDetails.ownerEmail),

ownerAvatar stays undefined, which already renders the default avatar fallback via avatarID={item.ownerAccountID} at WorkspaceTableRow.tsx#L190-L195, so the avatar is correct as well.

This shows the owner's email (and avatar) immediately, with no extra API call. Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Dispatch an OpenPublicProfilePage/personal-details fetch for the non-member owner account so PERSONAL_DETAILS_LIST gets populated and the existing lookup starts succeeding. This would yield the full display name, but it adds a network round-trip per pending workspace, shows a flicker/empty state until it resolves, and offline shows nothing — whereas policyDetailsForNonMembers.ownerEmail is already in Onyx and renders instantly offline. The fallback approach is cleaner and reuses data we already hold.

[x-dev90]

Proposal

What is the root cause of that problem?

The pending join request row gets its workspace name/type/avatar from policyDetailsForNonMembers, but it does not preserve the owner email from that same payload.

PolicyDetailsForNonMembers already includes ownerEmail on the public pending-workspace payload:

App/src/types/onyx/Policy.ts

Lines 1936 to 1944 in 62df01f

	type PolicyDetailsForNonMembers = {
	/** Name of the policy */
	name: string;
	/** Policy owner account ID */
	ownerAccountID: number;
	/** Policy owner e-mail */
	ownerEmail: string;

However, createWorkspaceListPoliciesSelector only projects name, type, ownerAccountID, and avatar, dropping ownerEmail:

App/src/selectors/Policy.ts

Lines 80 to 108 in 62df01f

	nonMemberDetails?: Pick<PolicyDetailsForNonMembers, 'name' | 'type' | 'ownerAccountID' | 'avatar'> & {policyID: string};
	};
	/**
	* Creates a selector returning a light, flat projection of the policies shown on the workspaces list,
	* so the page doesn't re-render when deep, frequently mutated policy fields change (isLoading* flags,
	* employeeList, customUnits, connections, etc.).
	*/
	const createWorkspaceListPoliciesSelector =
	(currentUserLogin: string | undefined) =>
	(policies: OnyxCollection<Policy>): WorkspaceListPolicy[] => {
	const result: WorkspaceListPolicy[] = [];
	for (const policy of Object.values(policies ?? {})) {
	if (!policy || !shouldShowPolicy(policy, true, currentUserLogin)) {
	continue;
	}
	const isJoinRequestPending = !!policy.isJoinRequestPending && !!policy.policyDetailsForNonMembers;
	let nonMemberDetails: WorkspaceListPolicy['nonMemberDetails'];
	if (isJoinRequestPending) {
	const nonMemberEntry = Object.entries(policy.policyDetailsForNonMembers ?? {}).at(0);
	if (nonMemberEntry) {
	const [nonMemberPolicyID, details] = nonMemberEntry;
	nonMemberDetails = {
	policyID: nonMemberPolicyID,
	name: details.name,
	type: details.type,
	ownerAccountID: details.ownerAccountID,
	avatar: details.avatar,

Then WorkspacesListPage renders pending workspace owner text only when PERSONAL_DETAILS_LIST has an entry for nonMemberDetails.ownerAccountID:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 96 to 115 in 62df01f

	if (policy.isJoinRequestPending && policy.nonMemberDetails) {
	const {policyID, ownerAccountID} = policy.nonMemberDetails;
	const ownerDetails = ownerAccountID ? ownerDisplayDetails?.[ownerAccountID] : undefined;
	const pendingWorkspaceRow: WorkspaceRowData = {
	keyForList: policyID,
	policyID,
	disabled: true,
	errors: undefined,
	type: policy.nonMemberDetails.type,
	title: policy.nonMemberDetails.name,
	role: CONST.POLICY.ROLE.USER,
	isDeleted: false,
	isJoinRequestPending: true,
	isDefault: activePolicyID === policyID,
	shouldAnimateInHighlight: duplicateWorkspace?.policyID === policyID,
	ownerAccountID,
	ownerLogin: ownerDetails ? ownerDetails.login : undefined,
	ownerAvatar: ownerDetails ? ownerDetails.avatar : undefined,
	ownerName: ownerDetails ? getDisplayNameOrDefault(ownerDetails) : undefined,

For pending join request workspaces, the owner may not be present in the local personal details cache. In that case, ownerName becomes undefined, and the row renders an empty owner column even though the pending workspace payload already contains the owner email.

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

Keep ownerEmail in the lightweight pending-workspace projection and use it as the text fallback for pending join request rows.

Required changes:

• Add ownerEmail to WorkspaceListPolicy.nonMemberDetails.
• Copy details.ownerEmail inside createWorkspaceListPoliciesSelector.
• In WorkspacesListPage, compute pending-row ownerName with getDisplayNameOrDefault(ownerDetails, ownerEmail, false).
• Set ownerLogin to ownerDetails?.login ?? ownerEmail for pending rows.
• Update tests/unit/PolicySelectorTest.ts so pending non-member details must preserve ownerEmail.

Tests to add/update:

• Unit test: createWorkspaceListPoliciesSelector preserves ownerEmail in nonMemberDetails.
• Manual web regression: request to join a workspace by invite deeplink, open Workspaces, and verify the pending row shows owner details even when the owner is not already in PERSONAL_DETAILS_LIST.

I considered relying only on PERSONAL_DETAILS_LIST, but that keeps the same failure mode because pending join requests can reference owners whose personal details are not cached locally. Preserving ownerEmail from policyDetailsForNonMembers is the minimal root-cause fix because that payload is already the source of public pending-workspace details.

What alternative solutions did you explore? (Optional)

[dilshodmackbook-sketch]

Proposal

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

A workspace with a pending join request shows a blank owner column in the Workspaces list instead of the owner's details.

What is the root cause of that problem?

For a pending join request workspace we build the row's owner fields purely from ownerDisplayDetails, which is a narrow subscription to ONYXKEYS.PERSONAL_DETAILS_LIST:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 85 to 100 in cda43db

	return;
	}
	Navigation.navigate(workspaceRoute);
	};
	/**
	* Add free policies (workspaces) to the list of menu items and returns the list of menu items
	*/
	const workspaceRows: WorkspaceRowData[] = [];
	for (const policy of workspaceListPolicies ?? []) {
	if (policy.isJoinRequestPending && policy.nonMemberDetails) {
	const {policyID, ownerAccountID} = policy.nonMemberDetails;
	const ownerDetails = ownerAccountID ? ownerDisplayDetails?.[ownerAccountID] : undefined;
	const pendingWorkspaceRow: WorkspaceRowData = {

In the pending branch we look the owner up by policyInfo.ownerAccountID and only set ownerLogin/ownerName/ownerAvatar when that lookup returns something:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 162 to 180 in cda43db

	if (duplicateWorkspaceIndex < 0) {
	return;
	}
	tableRef.current?.scrollToIndex({index: duplicateWorkspaceIndex, animated: false});
	const handle = TransitionTracker.runAfterTransitions({
	callback: () => clearDuplicateWorkspace(),
	});
	return () => handle.cancel();
	}, [duplicateWorkspace?.policyID, isFocused, workspaceRows.length]);
	// Scroll to the top when the list gets its first workspace, so it's visible. On web, returning from the create
	// flow restores the scroll position the empty list had (it was scrolled down to reach the "New workspace" button),
	// which would otherwise hide the new row — so reset after the navigation transition, once that restore has run.
	const wasWorkspaceListEmptyRef = useRef(workspaceRows.length === 0);
	useEffect(() => {
	if (workspaceRows.length === 0) {
	wasWorkspaceListEmptyRef.current = true;

The problem is that the owner of a workspace we have only requested to join is a non-member, so their record is normally not present in our PERSONAL_DETAILS_LIST. The selector therefore skips that account ID (it continues when the detail is missing):

App/src/selectors/PersonalDetails.ts

Lines 26 to 38 in cda43db

	const createDisplayDetailsByAccountIDsSelector =
	(accountIDs: number[]) =>
	(personalDetailsList: OnyxEntry<PersonalDetailsList>): Record<number, DisplayDetails> => {
	const result: Record<number, DisplayDetails> = {};
	for (const accountID of accountIDs) {
	const detail = personalDetailsList?.[accountID];
	if (!detail) {
	continue;
	}
	result[accountID] = {accountID: detail.accountID, displayName: detail.displayName, login: detail.login, avatar: detail.avatar};
	}
	return result;
	};

So ownerDetails is undefined, and ownerLogin/ownerName/ownerAvatar all fall through to undefined. The row renders with formattedOwnerName = item.ownerName ?? '' → empty:

App/src/components/Tables/WorkspaceListTable/WorkspaceTableRow.tsx

Line 48 in cda43db

The owner identity we need is actually already on the policy — policyDetailsForNonMembers carries ownerEmail (and ownerAccountID) for exactly this non-member case, but we never use it:

App/src/types/onyx/Policy.ts

Lines 1935 to 1950 in cda43db

	/** Details of public policy */
	type PolicyDetailsForNonMembers = {
	/** Name of the policy */
	name: string;
	/** Policy owner account ID */
	ownerAccountID: number;
	/** Policy owner e-mail */
	ownerEmail: string;
	/** Policy type */
	type: ValueOf<typeof CONST.POLICY.TYPE>;
	/** Policy avatar */
	avatar?: string;

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

In the pending join request branch, fall back to the owner data already present in policyDetailsForNonMembers when the personal-details lookup is empty. We build a fallback detail from policyInfo.ownerEmail so the existing ownerLogin/ownerName/ownerAvatar derivations keep working:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 162 to 180 in cda43db

	if (duplicateWorkspaceIndex < 0) {
	return;
	}
	tableRef.current?.scrollToIndex({index: duplicateWorkspaceIndex, animated: false});
	const handle = TransitionTracker.runAfterTransitions({
	callback: () => clearDuplicateWorkspace(),
	});
	return () => handle.cancel();
	}, [duplicateWorkspace?.policyID, isFocused, workspaceRows.length]);
	// Scroll to the top when the list gets its first workspace, so it's visible. On web, returning from the create
	// flow restores the scroll position the empty list had (it was scrolled down to reach the "New workspace" button),
	// which would otherwise hide the new row — so reset after the navigation transition, once that restore has run.
	const wasWorkspaceListEmptyRef = useRef(workspaceRows.length === 0);
	useEffect(() => {
	if (workspaceRows.length === 0) {
	wasWorkspaceListEmptyRef.current = true;

const policyOwnerAccountID = policyInfo.ownerAccountID;
const ownerDetails =
    (policyOwnerAccountID ? ownerDisplayDetails?.[policyOwnerAccountID] : undefined) ??
    (policyInfo.ownerEmail ? {accountID: policyOwnerAccountID, login: policyInfo.ownerEmail, displayName: undefined, avatar: undefined} : undefined);

getDisplayNameOrDefault(ownerDetails) then returns the formatted ownerEmail, and the avatar gracefully defaults from ownerAccountID. When the full personal details are present (e.g. after the owner becomes known), we still use them.

Alternatively we can keep the lookup as-is and only fall back at the field level, e.g. ownerLogin: ownerDetails ? ownerDetails.login : policyInfo.ownerEmail and ownerName: ownerDetails ? getDisplayNameOrDefault(ownerDetails) : formatPhoneNumber(policyInfo.ownerEmail), but the single fallback object above keeps all three fields consistent in one place.

Note: ownerEmail is already part of the PolicyDetailsForNonMembers payload, so this needs no extra API/data fetch.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Render WorkspacesListPage with a policy where isJoinRequestPending is true and policyDetailsForNonMembers[policyID].ownerEmail is set while the owner's account ID is absent from PERSONAL_DETAILS_LIST, and assert the row's owner column shows the owner email/name rather than an empty string.

What alternative solutions did you explore? (Optional)

We could have the backend include the non-member owner in PERSONAL_DETAILS_LIST whenever a pending join policy is returned, but that's a heavier server change for data the client already receives in policyDetailsForNonMembers.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

For a workspace you have a pending join request to, you aren't a member, so the owner's profile is never in your local PERSONAL_DETAILS_LIST. But WorkspacesListPage resolves the owner name/avatar exclusively from that Onyx key, so the owner column comes back empty.

The page collects owner account IDs and subscribes to personal details for them:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 73 to 80 in cda43db

	const ownerAccountIDs = [
	...new Set(
	(workspaceListPolicies ?? [])
	.map((policy) => (policy.isJoinRequestPending && policy.nonMemberDetails ? policy.nonMemberDetails.ownerAccountID : policy.ownerAccountID))
	.filter((id): id is number => id !== undefined),
	),
	];
	const [ownerDisplayDetails] = useOnyx(ONYXKEYS.PERSONAL_DETAILS_LIST, {selector: createDisplayDetailsByAccountIDsSelector(ownerAccountIDs)}, [workspaceListPolicies]);

For the pending-join branch it then looks the owner up in that result and maps every owner field from it:

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 96 to 115 in cda43db

	if (policy.isJoinRequestPending && policy.nonMemberDetails) {
	const {policyID, ownerAccountID} = policy.nonMemberDetails;
	const ownerDetails = ownerAccountID ? ownerDisplayDetails?.[ownerAccountID] : undefined;
	const pendingWorkspaceRow: WorkspaceRowData = {
	keyForList: policyID,
	policyID,
	disabled: true,
	errors: undefined,
	type: policy.nonMemberDetails.type,
	title: policy.nonMemberDetails.name,
	role: CONST.POLICY.ROLE.USER,
	isDeleted: false,
	isJoinRequestPending: true,
	isDefault: activePolicyID === policyID,
	shouldAnimateInHighlight: duplicateWorkspace?.policyID === policyID,
	ownerAccountID,
	ownerLogin: ownerDetails ? ownerDetails.login : undefined,
	ownerAvatar: ownerDetails ? ownerDetails.avatar : undefined,
	ownerName: ownerDetails ? getDisplayNameOrDefault(ownerDetails) : undefined,

The selector behind ownerDisplayDetails only reads PERSONAL_DETAILS_LIST and silently skips any account ID that isn't present:

App/src/selectors/PersonalDetails.ts

Lines 26 to 38 in cda43db

	const createDisplayDetailsByAccountIDsSelector =
	(accountIDs: number[]) =>
	(personalDetailsList: OnyxEntry<PersonalDetailsList>): Record<number, DisplayDetails> => {
	const result: Record<number, DisplayDetails> = {};
	for (const accountID of accountIDs) {
	const detail = personalDetailsList?.[accountID];
	if (!detail) {
	continue;
	}
	result[accountID] = {accountID: detail.accountID, displayName: detail.displayName, login: detail.login, avatar: detail.avatar};
	}
	return result;
	};

So for a non-member owner, ownerDisplayDetails?.[ownerAccountID] is undefined → ownerName/ownerLogin/ownerAvatar are all undefined. The row then renders an empty owner because it falls back to '':

App/src/components/Tables/WorkspaceListTable/WorkspaceTableRow.tsx

Line 49 in cda43db

const formattedOwnerName = item.ownerName ?? '';

The owner identity we do have for a non-member lives on policyDetailsForNonMembers, which carries ownerEmail (and ownerAccountID):

App/src/types/onyx/Policy.ts

Lines 1936 to 1951 in cda43db

	type PolicyDetailsForNonMembers = {
	/** Name of the policy */
	name: string;
	/** Policy owner account ID */
	ownerAccountID: number;
	/** Policy owner e-mail */
	ownerEmail: string;
	/** Policy type */
	type: ValueOf<typeof CONST.POLICY.TYPE>;
	/** Policy avatar */
	avatar?: string;
	};

But the workspaces-list projection added in #93293 (createWorkspaceListPoliciesSelector) drops ownerEmail entirely — its nonMemberDetails only picks name | type | ownerAccountID | avatar, so the page can't reach the one field that would let it show the owner:

App/src/selectors/Policy.ts

Lines 96 to 110 in cda43db

	const isJoinRequestPending = !!policy.isJoinRequestPending && !!policy.policyDetailsForNonMembers;
	let nonMemberDetails: WorkspaceListPolicy['nonMemberDetails'];
	if (isJoinRequestPending) {
	const nonMemberEntry = Object.entries(policy.policyDetailsForNonMembers ?? {}).at(0);
	if (nonMemberEntry) {
	const [nonMemberPolicyID, details] = nonMemberEntry;
	nonMemberDetails = {
	policyID: nonMemberPolicyID,
	name: details.name,
	type: details.type,
	ownerAccountID: details.ownerAccountID,
	avatar: details.avatar,
	};
	}

One thing worth flagging: this is not a regression introduced by #93293. The pre-refactor code resolved the owner the exact same way (ownerDisplayDetails?.[policyOwnerAccountID] against personal details), so pending-join rows were already blank. #93293's QA test step 7 ("verify the row shows... the correct owner details") is simply what surfaced the existing bug — which is why it's tagged as the bug source.

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

Source the owner from the non-member payload instead of relying on personal details that don't exist for a non-member. Two small edits, fix layer is selector (data) + render-mapping:

1. In createWorkspaceListPoliciesSelector (src/selectors/Policy.ts#L96-L110), add ownerEmail to the projected nonMemberDetails object, and add 'ownerEmail' to the Pick<PolicyDetailsForNonMembers, …> on src/selectors/Policy.ts#L80. This re-exposes the only owner-identity field available for non-members.

2. In the pending-join branch of WorkspacesListPage (#L96-L115), fall back to that email when the personal-details lookup is empty, e.g. ownerLogin = ownerDetails?.login ?? nonMemberDetails.ownerEmail and ownerName = ownerDetails ? getDisplayNameOrDefault(ownerDetails) : nonMemberDetails.ownerEmail. Keep the existing ownerDisplayDetails lookup as the preferred source so that if the owner does happen to be in personal details (e.g. a prior chat) you still get the richer display name.

The owner avatar stays a default placeholder for the pending state — PolicyDetailsForNonMembers only carries the workspace avatar, not the owner's, so there's no real owner avatar to show. WorkspaceTableRow already renders a default from avatarID={item.ownerAccountID} when ownerAvatar is undefined, so the row will show the owner email/name next to a default avatar, which satisfies "owner details should be shown".

No offline/optimistic concern here: policyDetailsForNonMembers is the same cached Onyx data the row already uses for the workspace name/type, so the owner email renders offline too.

What alternative solutions did you explore? (Optional)

Have the backend push the owner's personal details to non-members so the existing createDisplayDetailsByAccountIDsSelector lookup resolves. Rejected: that's a heavier server-side change to send full profiles to people who aren't workspace members, and the client already receives ownerEmail for exactly this purpose — there's no reason to round-trip more data.

Treat it as a stale-subscription / dependency-array problem on the new ownerDisplayDetails useOnyx. Rejected and falsifiable: createDisplayDetailsByAccountIDsSelector (PersonalDetails.ts#L31-L34) continues whenever the account isn't in the list, so the owner is absent regardless of timing or memoization — fresher data wouldn't help.

Fix it in the render layer (WorkspaceTableRow). Rejected: the row faithfully renders item.ownerName ?? '' (#L49); the field arrives undefined from the page, so the data is missing one layer up — patching the row would just paper over the empty value.