Rooms- Number of members shown as "1 member" in admins/WS rooms when user sign in back

[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.89-3
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91056
Email or phone of affected tester (no customers): applausetester+ck52826@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11/Chrome, Pixel 8a/Android 16, Iphone 16/18.7.1
App Component: Workspace Settings

Action Performed:

Precondition:
Admin has workspaces & has created rooms in some workspaces. Added few members to WS rooms

1. Navigate to staging.new.expensify.com
2. Go to WS settings >> # Rooms
3. Observe the actual number of members in #admins & workspace rooms
4. Sign out & sign in back
5. Go to WS settings >> # Rooms
6. Observe the number of members shown as "1 member" in #admins & workspace rooms

Expected Result:

Correct numbers to members that were added should be displayed in #admins & workspace rooms after logging in back

Actual Result:

Number of members always shown as "1 member" in admins/WS rooms when user sign in back though there are more members added

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7166501_1780071761493._2__Applause_s_Workspace_-_Rooms_-_Google_Chrome_2026-05-29_12-21-16.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7166501

[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/9e546901308864aad700d9b4a3741f74b24bf3b029b3deaabf1fa53b051e7c98

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #91056

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

The new rooms table introduced by PR #91056 computes each row's memberCount from report.participants via getParticipantsAccountIDsForDisplay, but report.participants for chat rooms is only fully hydrated after OpenReport (or a Pusher membership push) has been processed for that specific room.

The new OpenPolicyRoomsPage read command only sends {policyID} and the App has no client-side merge that primes per‑room participants. After sign‑out (Onyx wiped) + sign‑in, OpenApp rehydrates the chat-room stubs with only the current user in participants, so WorkspaceRoomsPage.tsx:67 collapses every row to 1 member.

Before sign‑out the count looked right only because the user had visited those rooms during the session — each OpenReport backfilled participants — but that state is derived, not persisted, and is lost across the sign‑in cycle.

Investigation details

Data flow that produces the bug

1. Sign‑in → OpenApp populates the reports_* collection with minimal chat‑room stubs (participants only contains the current account).
2. WorkspaceRoomsPage mounts → fires openPolicyRoomsPage(policyID) (Room.ts:6).
3. The request payload is just {policyID} (OpenPolicyRoomsPageParams.ts) and there's no client‑side success handler that writes per‑room participants into Onyx.
4. The selector policyChatRoomsSelector projects whatever Onyx already contains — it can't invent participants that aren't there.
5. Each row computes memberCount: getParticipantsAccountIDsForDisplay(report, true, false, false, undefined, personalDetails).length (WorkspaceRoomsPage.tsx:67). With an effectively empty participants map, this returns [currentUserAccountID] and the row renders "1 member".

Why the symptom is "1 member" (not "0 members")

getParticipantsAccountIDsForDisplay always includes the current account when participants contains it as the lone stub, hence the floor of 1.

Where the fix needs to land

The minimum‑risk, frontend‑only mitigation is in the new App code. However, the correct long‑term fix is to have OpenPolicyRoomsPage return participant data for every room and merge it into the reports collection — that work spans both Expensify/App (response handling / success data merge) and Expensify/Web-Expensify (backend command).

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

Make OpenPolicyRoomsPage return participants for every room on the page and merge them into Onyx so the table can read an accurate count regardless of whether the user has visited the room.

Concretely, on the App side:

• Add a successData (or response merge) to openPolicyRoomsPage in src/libs/actions/Policy/Room.ts that writes per‑room participants (or a precomputed participantsList / participantCount) into the reports_* collection.
• In WorkspaceRoomsPage.tsx:67, prefer that returned field (e.g. report.participantCount ?? getParticipantsAccountIDsForDisplay(...).length). As a defensive UI choice, when no count is available render a skeleton/— rather than the misleading 1 member.

This requires a corresponding backend change in Expensify/Web-Expensify to make OpenPolicyRoomsPage actually return that data. That part is outside the Expensify/App repo and needs to be picked up by an internal Expensify engineer.

Until the backend ships, a low‑risk client‑only stopgap is to render — (or hide the column) when participants only contains the current user, so the UI no longer asserts an incorrect "1 member".

What alternative solutions did you explore? (Optional)

• Fire OpenReport for every room on mount. Would hydrate participants but is wasteful (N requests, defeats the purpose of a single rooms‑page read) and breaks the design intent of the new endpoint.
• Read from report.participantsList instead of participants. participantsList is a legacy denormalized field that isn't reliably populated for chat rooms in OpenApp either, so this would only partially mask the bug.
• Cache the previous session's participants in Onyx across sign‑out. Wrong direction — Onyx wipe on sign‑out is intentional, and stale participant lists would create worse bugs than the current one.

---

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

Note: the fully correct fix also requires backend work in Expensify/Web-Expensify (to make OpenPolicyRoomsPage return per‑room participants). MelvinBot cannot implement that — an internal Expensify engineer needs to pair the App-side change with the backend change.