Room-Room is still visible on user B's side after user A removing it from room member

[applause-bot]

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

---

Version Number: v9.4.45-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96734
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 27 Beta, Samsung Galaxy A52 / Android 14
App Component: Workspace Settings

Action Performed:

Preconditions:
-prepare 2 accounts (user A & user B)

• user A create 2 workspace (Alfa & Beta) and invite user B to both workspaces

Steps:

1. as User A create room in Alfa and Invite User B to that room member
2. as User B go to Alfa -> #rooms and validate that new room exists
3. as User A invite another user to the room
4. as User B check that members count is updated, then navigate to room chat
5. as User A remove user B from the room
6. as User B note that it automatically navigated to concierge room
7. as user B navigate to Alfa -> #room

Expected Result:

the room shouldn't visible to user B's side and user B can't access to the room chat since user A already removed user B from room member. this also should be in accordance with automatically navigated to concierge chat in step 7

Actual Result:

Room is still visible on user B's side after user A removing it from room member

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7220066_1785256852557.bandicam_2026-07-28_23-25-32-537.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @marcaaron

[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/7f253c04aacb7d5757f5f1d4da6ccc6eb6b00f1a2bcf38b35d4d3e3533138541

[MelvinBot]

Issue Analysis

Root Cause: A room's visibility in User B's LHN and their ability to open it are computed purely from local Onyx report state — the report existing, notificationPreference !== 'hidden', and canAccessReport (which only checks the default-room beta + errorFields.notFound). There is no membership/participant gate anywhere in this pipeline, and chat rooms are explicitly allowed to show even with no participants. So being removed from a room does not, by itself, hide it.

When User A removes User B, the removeFromRoom action only writes the participant removal to User A's Onyx (Report/index.ts:5277-5342). Nothing sets User B's own notificationPreference to hidden — unlike voluntarily leaving a room, which does (Report/index.ts:4954-4972). That's why leaving hides the room but being removed does not.

The auto-navigation to Concierge (step 7) fires only because the backend transiently clears the report from User B's Onyx, which trips wasReportRemoved in ReportNavigateAwayHandler.tsx:148-198. But that clearing isn't durable: when User B navigates back to Workspace → #rooms and opens the room, withReportOrNotFound / the LHN calls OpenReport (Report/index.ts:1534), the room is re-served and re-populated in Onyx (its successData even clears errorFields.notFound), and with no hidden preference and no notFound flag the room reappears and reopens.

Where the fix lives: The durable state the App relies on to hide/block a room (a hidden notification preference for the removed user, errorFields.notFound, an archive flag, or simply not re-serving the room to a non-member on OpenReport) has to be pushed by the backend on member removal — the way voluntary leave already results in a hidden preference. This appears to be a backend/internal issue and a separate internal investigation is needed. It should be escalated to an internal engineer; a frontend-only change in App can't reliably fix it because App has no authoritative membership signal to gate on once the backend keeps serving the room.

Investigation details & evidence

• No membership gate in LHN logic: reasonForReportToBeInOptionList / shouldReportBeInOptionList, ReportUtils.ts:9841-10033 — rooms bypass the "no participants" exclusion; nothing checks isReportParticipant(currentUser).
• LHN display gate: SidebarUtils.ts:326-378 only checks isHiddenForCurrentUser + shouldReportBeInOptionList.
• Hidden gate depends on notificationPreference: isHiddenForCurrentUser, ReportUtils.ts:2386-2397.
• Open/not-found gate: withReportOrNotFound.tsx:104-140 + canAccessReport, ReportUtils.ts:9366-9377 — only default-room beta + errorFields.notFound, no membership check.

Alternative explanation considered: that the App simply isn't reacting to a removal push. Ruled out — the auto-navigation in step 7 proves the removal update does reach User B; it's just transient (report cleared) rather than a durable hide, so re-opening re-fetches the room.

Open question (backend): exactly what Onyx update the backend pushes to the removed user on removal, and whether OpenReport should stop serving the room to a non-member — this determines the precise backend fix and can't be confirmed from the App repo alone.

Confidence: Medium — the App-side behavior (no membership gate; removal never sets a durable hide locally) is verified in code, but the exact fix requires backend behavior that isn't visible from this repo.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[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/~022082150919023007913

[brunovjk]

I agree with MelvinBot’s analysis here. This looks like it needs an internal/backend fix rather than an App-only fix. Could you please help confirm whether this should be handled purely on the backend? Thank you.

🎀 👀 🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @marcaaron, see https://stackoverflow.com/c/expensify/questions/7972 for more details.