Workspace Members - Newly invited member does not appear in the Members table after completing the invite flow

[yuwenmemon]

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

---

Version Number: 9.4.45-6
Reproducible in staging?: Yes
Reproducible in production?: Yes (production version 9.4.44-6)
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A
Email or phone of affected tester (no customers): yuwen@expensify.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Yuwen
Slack conversation (hyperlinked to channel name):

Action Performed:

1. Go to a workspace's Members page (e.g. staging.new.expensify.com/workspaces/<policyID>/members).
2. Click Invite member.
3. In the "Name, email, or phone number" field, type a search term (e.g. "yuwen") to filter the contacts list.
4. Select a contact from the filtered list (e.g. Yuwen Memon, yuwen+2@expensify.com) and click Next.
5. On the "Confirm details" screen, leave Role as "Member" and the default message, then click Invite.

Expected Result:

After clicking Invite, the newly invited member appears in the workspace Members table, and "Total workspace members" increments accordingly.

Actual Result:

The invite flow completes and returns to the Members page, but the newly invited member never appears in the table — "Total workspace members" stays unchanged at 1. The member is still missing even after refreshing the page.

Workaround:

None found — the member does not appear even after a page refresh.

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Kapture.2026-07-28.at.13.10.20.mp4

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082205459718358487
• Upwork Job ID: 2082205459718358487
• Last Price Increase: 2026-07-28

[MelvinBot]

Proposal

What is the root cause of that problem?

The invite flow assigns server-searched contacts a fabricated accountID, and the newly-refactored, accountID-keyed selection flow never reconciles it to the contact's real accountID. That broken accountID then breaks the employeeList ↔ personalDetails join the Members table depends on, so the invited member is filtered out and the count stays at 1.

Walking the flow (repro = typing a search term, which triggers a server search rather than picking an already-known contact):

1. A server-searched "invite" option is created with an optimistic accountID that is just a hash of the login (generateAccountID → hashText(login)), not the person's real accountID.
2. The invite selection now keys entirely on accountID.toString() and the "Next" step builds invitedEmailsToAccountIDs[login] = accountID from the selected options — so the correct email is captured, but paired with the fabricated hashed accountID.
3. The Members table renders only members it can join from policy.employeeList (keyed by email) to a personalDetails record by accountID — if (!details) continue. When the optimistic/hashed accountID doesn't line up with the member's real personalDetails entry, the row is dropped and memberCount (which is just data.length) never increments.

A secondary amplifier: the page seeds its server refetch (openWorkspaceMembersPage) with only the emails that already resolve to a personalDetails login, so a member stuck without a joinable personalDetails entry can remain excluded across refreshes.

⚠️ Confidence: medium. The regressing subsystem — the accountID-keyed invite selection mishandling the optimistic hashed accountID for server-searched contacts — is well-supported by code. I could not fully confirm the exact terminal failure with runtime evidence (VictoriaLogs isn't reachable from this run). Specifically, I could not distinguish "the invite payload ends up empty/dropped" from "the member is added but never renders because of the accountID/personalDetails join." To confirm, capture the AddMembersToWorkspace request's employees param for a failing invite, or inspect the Onyx employeeList + personalDetails state immediately after a failed invite.

Code references (App @ 49c0d8e)

• Optimistic hashed accountID for a searched contact: src/libs/UserUtils.ts:213-217
• Selection keyed on accountID.toString() (no reconciliation to real accountID): src/hooks/usePersonalDetailSearchSelector/base.ts:194-213
• "Next" builds invitedEmailsToAccountIDs from selectedOptions: src/pages/workspace/DynamicWorkspaceInvitePage.tsx:184-200
• Invite submit → addMembersToWorkspace: src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx:181-203
• Optimistic employeeList + personalDetails keyed by email/accountID: src/libs/actions/Policy/Member.ts:864-900
• Members table drops any member with no joinable personalDetails: src/pages/workspace/WorkspaceMembersPage.tsx:371-391
• Email→accountID map also skips members without a personalDetails login: src/libs/PolicyUtils.ts:788-792
• Refetch seeded only with already-joinable emails (amplifier): src/pages/workspace/WorkspaceMembersPage.tsx:216-223

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

• When a server search (SearchForUsers) resolves and the selected contact's real personalDetails become available, reconcile the invite selection so it points at the real accountID instead of the optimistic hashed one — the selection model in usePersonalDetailSearchSelector should not silently retain a stale/fabricated accountID for a contact that now has a real one.
• Alternatively (or additionally), make the invite selection key on login for userToInvite/optimistic options rather than the hashed accountID, since the backend AddMembersToWorkspace keys on email anyway.
• Make the Members table resilient to an accountID mismatch — fall back to joining employeeList entries by email when the accountID lookup misses — so a validly-invited member can't be silently hidden.

What alternative solutions did you explore? (Optional)

If runtime evidence shows the employees payload is genuinely empty at submit time, the fix narrows to the selection-reconciliation gap alone (guard the "Invite" submit against an empty selection and re-sync selectedAccountIDs/extraOptions after search resolves).

Possibly-related open issues (not confirmed duplicates)

• [Due for payment 2026-07-29] [$250] WS settings - Invite member from WS settings then clicking on it gives error in RHP #95725 — WS settings: invite member then clicking it errors in RHP.
• [Exploratory] Members - Invited member's details page turns into "Not here" #94902 — Invited member's details page turns into "Not here".

Both touch the workspace invite / member-rendering path and may share the accountID/personalDetails mismatch above, but neither is a confirmed duplicate of this one.

---

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

[melvin-bot]

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

[melvin-bot]

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

[yuwenmemon]

Oh, I know why this happened. This is because I invited expensify.com domains.