[$250] Room - The room is shown in the search router after leaving it

[lanitochka17]

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.58-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: https://test-management.browserstack.com/projects/2219752/folder/13176685/test-cases/41236597
Email or phone of affected tester (no customers): applausetester+ag090426b@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.3
App Component: Search

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Log in as a workspace member
3. Create a workspace room
4. Click on the room header > Leave
5. Click on the search router
6. Search for the room you just left

Expected Result:

The room is not shown in the search router or in the search results.

Actual Result:

The room is shown in the search router and in the search results.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7126950_1775841343195.room_is_displayed.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ShridharGoel

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042655851540226026
• Upwork Job ID: 2042655851540226026
• Last Price Increase: 2026-04-10

[MelvinBot]

Proposal

What is the root cause of that problem?

When a workspace member leaves a workspace room, leaveRoom (Report/index.ts:4420-4438) sets notificationPreference: HIDDEN on the participant but keeps the report in Onyx (unlike non-members, where the report is effectively removed).

The search router filters hidden items via excludeHiddenThreads at OptionsListUtils/index.ts:2688-2689:

recentReportOptions.filter((option) => !option.isThread || option.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN)

This condition only filters threads with HIDDEN preference. Workspace rooms have isThread = false, so !option.isThread evaluates to true and the filter short-circuits — the room always passes through regardless of its notification preference.

The LHN sidebar does not have this bug because it has a separate, explicit isHiddenForCurrentUser(report) check at SidebarUtils.ts:258,286.

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

Change the filter at OptionsListUtils/index.ts:2689 to also exclude non-thread reports with HIDDEN notification preference. The condition should filter out any report with notificationPreference === HIDDEN, not just threads:

recentReportOptions.filter((option) => option.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN)

The parameter name excludeHiddenThreads should also be renamed to excludeHidden (or similar) to reflect the broader scope, and updated at all call sites.

What alternative solutions did you explore? (Optional)

An alternative would be adding an isHiddenForCurrentUser check inside shouldReportBeInOptionList / reasonForReportToBeInOptionList (ReportUtils.ts:9513-9693), similar to what SidebarUtils.ts does. However, this is a heavier change and could have broader side effects. The simpler fix at the existing filter point is more targeted and lower risk.

---

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

[melvin-bot]

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

[abbasifaizan70]

Proposal

What is the root cause of that problem?

When a workspace member leaves a workspace room, the room is not deleted from Onyx. Instead, that member's participant preference is set to HIDDEN, so search experiences should treat that room as hidden.

App/src/libs/actions/Report/index.ts

Lines 4416 to 4432 in 40dea10

	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value:
	isWorkspaceMemberLeavingWorkspaceRoom || isChatThread
	? {
	participants: {
	[currentUserAccountID]: {
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	},
	},
	}
	: {
	reportID: null,
	stateNum: CONST.REPORT.STATE_NUM.APPROVED,
	statusNum: CONST.REPORT.STATUS_NUM.CLOSED,

The Search Router options pipeline currently excludes hidden threads only. Hidden chat rooms remain in recentReportOptions, so a room the user just left can still appear in Search Router and in router-driven search suggestions/results.

App/src/libs/OptionsListUtils/index.ts

Lines 2685 to 2687 in 40dea10

	if (excludeHiddenThreads) {
	recentReportOptions = recentReportOptions.filter((option) => !option.isThread || option.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN);
	}

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

App/src/libs/OptionsListUtils/index.ts

Lines 2685 to 2687 in 40dea10

	if (excludeHiddenThreads) {
	recentReportOptions = recentReportOptions.filter((option) => !option.isThread || option.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN);
	}

if (excludeHiddenThreads) {
    recentReportOptions = recentReportOptions.filter((option) => option.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN);
}

App/src/components/Search/SearchRouter/SearchRouter.tsx

Lines 107 to 115 in 40dea10

	if (!reportForContextualSearch) {
	const report = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${contextualReportID}`];
	if (!report) {
	return undefined;
	}
	const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
	const option = createOptionFromReport(report, personalDetails, contextualReportIsArchived, reportPolicy, undefined, {showPersonalDetails: true});
	reportForContextualSearch = option;

if (!reportForContextualSearch) {
    const report = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${contextualReportID}`];
    if (!report || isHiddenForCurrentUser(report)) {
        return undefined;
    }

    const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
    const option = createOptionFromReport(report, personalDetails, contextualReportIsArchived, reportPolicy, undefined, {showPersonalDetails: true});
    reportForContextualSearch = option;
}

Demo

Screen.Recording.2026-04-10.at.10.36.00.PM.mp4

[github-actions]

⚠️ @abbasifaizan70 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @KJ21-ENG Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[ReaperOAK]

Proposal

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

After a workspace member leaves a workspace room (via the room header → Leave), the room continues to appear in both the search router autocomplete list and in search results. It should be fully hidden from the user, consistent with how the LHN sidebar already correctly hides it.

What is the root cause of that problem?

When a workspace member leaves a room, leaveRoom in src/libs/actions/Report/index.ts (L4397–4410) sets the participant's notificationPreference to CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN but keeps the report in Onyx (unlike non-members, where the report is effectively closed).

The LHN sidebar handles this correctly because SidebarUtils.ts (L261) explicitly calls isHiddenForCurrentUser(report) and returns shouldDisplay: false before even reaching shouldReportBeInOptionList.

However, the search router uses getSearchOptions → getValidOptions → the excludeHiddenThreads filter at src/libs/OptionsListUtils/index.ts (L2689–2690):

if (excludeHiddenThreads) {
    recentReportOptions = recentReportOptions.filter(
        (option) => !option.isThread || option.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN
    );
}

This filter uses a short-circuit OR: !option.isThread || .... Workspace rooms have isThread = false, so !option.isThread evaluates to true, the condition short-circuits, and the room always passes through regardless of its notification preference. The filter was designed only for threads, not for rooms or other report types that can also become hidden.

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

In src/libs/OptionsListUtils/index.ts, change the filter at L2689–2690 to use the existing isHiddenForCurrentUser utility (already imported in this file at L146 and used at L1286 and L3350) instead of the thread-only raw comparison:

// Before:
if (excludeHiddenThreads) {
    recentReportOptions = recentReportOptions.filter(
        (option) => !option.isThread || option.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN
    );
}

// After:
if (excludeHiddenThreads) {
    recentReportOptions = recentReportOptions.filter(
        (option) => !isHiddenForCurrentUser(option.notificationPreference)
    );
}

This removes the !option.isThread guard that was incorrectly allowing non-thread hidden reports (like workspace rooms) to pass through, and delegates the hidden check to the canonical isHiddenForCurrentUser utility — the same function the LHN sidebar already trusts.

Why isHiddenForCurrentUser instead of a bare !== HIDDEN check: The isHiddenForCurrentUser utility (src/libs/ReportUtils.ts L2247–2255) also handles null, undefined, and empty-string preferences as hidden, providing a consistent and more robust check. A bare !== HIDDEN comparison would miss these edge cases.

No other files need modification — the filter is the single point of failure and isHiddenForCurrentUser is already imported.

What alternative solutions did you explore? (Optional)

Alternative: Move the hidden check into reasonForReportToBeInOptionList / shouldReportBeInOptionList, mirroring the SidebarUtils approach of checking isHiddenForCurrentUser before evaluating the report for option list inclusion. This would be a more "architecturally pure" fix — filtering hidden reports at the eligibility level rather than post-hoc. However, reasonForReportToBeInOptionList is a shared function used across LHN, search, chat finder, and other contexts, some of which may legitimately need to include hidden reports (e.g., when a hidden report is pinned or has a draft, as SidebarUtils has explicit override logic for). Modifying it risks unintended side effects in other flows. The existing excludeHiddenThreads filter is the targeted, opt-in mechanism for the search router to strip hidden reports, and fixing it there is safer and more surgical.