[$250] orkspace-Search bar does not hide when member count decreases below 12 offline

[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.79-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: #91283
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Workspace Settings

Action Performed:

1. Launch app
2. Go to workspace settings
3. Invite 11 members
4. Go offline
5. Add a member
6. Search for a member
7. Delete the member shown in search results

Expected Result:

Search bar should automatically disappear and the search input should be cleared when the member count drops below 12, even in offline mode.

Actual Result:

Search bar does not hide when member count decreases below 12 offline.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7160632_1779448054654.Screenrecorder-2026-05-22-16-33-00-524.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057821845838500222
• Upwork Job ID: 2057821845838500222
• Last Price Increase: 2026-05-22

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

[MelvinBot]

Proposal

What is the root cause of that problem?

shouldShowSearchBar uses raw data.length to decide search bar visibility, which includes members with pendingAction: 'delete'. When offline, isDeletedPolicyEmployee() intentionally keeps pending-delete members in the list (so they render with a strikethrough). Since those members are still counted, data.length never drops below 12 and the search bar stays visible.

The memberCount variable on line 583 already correctly excludes pending-delete members — but shouldShowSearchBar doesn't use it.

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

Change line 590 in WorkspaceMembersPage.tsx from:

const shouldShowSearchBar = data.length >= CONST.STANDARD_LIST_ITEM_LIMIT;

to:

const shouldShowSearchBar = memberCount >= CONST.STANDARD_LIST_ITEM_LIMIT;

This reuses the already-computed memberCount (which filters out pending-delete members) so the search bar hides correctly in both online and offline scenarios.

---

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.

[MobileMage]

Proposal

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

When a workspace has 12 or more members and the user deletes a member while offline (dropping the effective count below 12), the search bar in the Workspace Members page does not hide and the search input is not cleared.

What is the root cause of that problem?

The root cause is a mismatch between how the "effective" member count is computed for the search bar threshold check versus how it is computed everywhere else on the page.

In WorkspaceMembersPage.tsx, filteredMembers is built by calling isDeletedPolicyEmployee for each entry in policy.employeeList. That helper returns false whenever isOffline is true, so offline-pending-delete members are intentionally kept in the list (to show them as greyed out / pending). This means the data array includes those members with pendingAction === DELETE.

Line 583 correctly accounts for this by computing memberCount that filters out pending-delete entries:

App/src/pages/workspace/WorkspaceMembersPage.tsx

Line 583 in 660202b

const memberCount = data.filter((member) => member.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE).length;

But line 590 computes shouldShowSearchBar using data.length (the raw count including pending-delete members) rather than memberCount:

App/src/pages/workspace/WorkspaceMembersPage.tsx

Line 590 in 660202b

const shouldShowSearchBar = data.length >= CONST.STANDARD_LIST_ITEM_LIMIT;

So when a user deletes a member offline, the member stays in data with pendingAction === DELETE, data.length stays at 12, and shouldShowSearchBar remains true even though the real member count has dropped to 11.

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

The fix is a one-line change in src/pages/workspace/WorkspaceMembersPage.tsx. Replace data.length with memberCount in the shouldShowSearchBar calculation on line 590. Since memberCount already filters out members whose pendingAction is DELETE, it correctly reflects the number of members that are actually visible and active — both online and offline. This makes the search bar threshold consistent with the count displayed in the header and hides the bar (and clears the input via the existing useSearchResults hook behavior) as soon as the effective member count drops below CONST.STANDARD_LIST_ITEM_LIMIT (12).

No other files need to change. The memberCount variable is defined immediately above shouldShowSearchBar on line 583 and is already in scope.

What alternative solutions did you explore? (Optional)

N/A

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The search bar visibility in the workspace members page is controlled by a threshold (typically 8 or more members), but the member count used to evaluate this threshold relies on data from Onyx which may not reflect optimistic updates correctly when offline. When a member is deleted offline, the optimistic removal isn't being factored into the count that determines whether the search bar should hide.

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

In src/pages/workspace/members/WorkspaceMembersPage.tsx, the member list shown to the user already includes optimistic removals (members are filtered out visually), but the condition controlling search bar visibility likely reads from a count that doesn't account for those pending deletions.

I'd suggest deriving the search bar visibility from the same filtered/displayed member list rather than the raw Onyx policy members object:

- const shouldShowSearchBar = Object.keys(policyMembers ?? {}).length >= CONST.WORKSPACE_MEMBERS_SEARCH_MIN_COUNT;
+ const shouldShowSearchBar = filteredAndSortedMembers.length >= CONST.WORKSPACE_MEMBERS_SEARCH_MIN_COUNT;

Additionally, when the search bar becomes hidden, the search input should be cleared:

+ useEffect(() => {
+     if (!shouldShowSearchBar) {
+         setSearchValue('');
+     }
+ }, [shouldShowSearchBar]);

This ensures that once the displayed member count (which already respects optimistic deletes) drops below the threshold, the search bar hides and clears its input — even in offline mode.

What alternative solutions did you explore?

An alternative would be to re-compute member count by subtracting the count of members with a pendingAction === 'delete', but deriving visibility from the already-filtered list is cleaner and more consistent with what the user actually sees.

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

The search bar visibility is derived from the raw member array length instead of the effective member count.

shouldShowSearchBar uses data.length:

const shouldShowSearchBar = data.length > CONST.SEARCH_ITEM_LIMIT;

When offline, isDeletedPolicyEmployee() returns false so a member deleted offline is kept in data (rendered with a strikethrough, pendingAction === DELETE). data.length therefore never drops, and the search bar stays visible. The memberCount variable right above it already excludes pending-delete members (it's the count shown in the header) — but shouldShowSearchBar doesn't use it.

There is also a second, related cause behind the "search input should be cleared" expectation. The list renders data={filteredData}, and filteredData is data narrowed by inputValue from useSearchResults. When the bar is hidden, the <SearchBar> unmounts but inputValue is page-level state — it is not reset. So even after the bar hides, the member list stays filtered by the stale search term.

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

1. In src/pages/workspace/WorkspaceMembersPage.tsx, base the threshold on the effective count:

- const shouldShowSearchBar = data.length > CONST.SEARCH_ITEM_LIMIT;
+ const shouldShowSearchBar = memberCount > CONST.SEARCH_ITEM_LIMIT;

memberCount already filters out pendingAction === DELETE entries, so the bar now hides as soon as the effective count drops below the limit — online and offline alike — and stays consistent with the header count.

2. Clear the stale search input when the bar is hidden, so the list isn't left filtered:

+ useEffect(() => {
+     if (shouldShowSearchBar || !inputValue) {
+         return;
+     }
+     setInputValue('');
+ }, [shouldShowSearchBar, inputValue, setInputValue]);

Together these make the bar disappear and the input clear when the member count drops below the limit offline, matching the expected result.

What alternative solutions did you explore? (Optional)

• Recompute the count inline (data.filter(...).length directly in shouldShowSearchBar) — rejected: memberCount already does exactly this one line above and is the value shown in the header, so reusing it keeps the threshold and the displayed count in sync and avoids duplicated logic.
• Use filteredData.length for the threshold — rejected: while a search is active filteredData is already narrowed to matches, so the bar would incorrectly hide itself mid-search whenever a query returned fewer than the limit.

[melvin-bot]

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

[aswin-s]

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

On Android and Web, when a workspace has 12 members and the user goes offline, adds a member, then deletes a member via search, the search bar remains visible even though the effective member count has dropped below 12. The search bar should hide (and its input clear) once the visible member count is under 12, matching online behavior.

What is the root cause of that problem?

In src/pages/workspace/WorkspaceMembersPage.tsx:590, shouldShowSearchBar = data.length >= CONST.STANDARD_LIST_ITEM_LIMIT is computed from the raw data array, which still contains members with pendingAction === DELETE while offline. The page already knows the correct displayed count — line 583 derives memberCount by filtering out pendingAction === DELETE entries — but that filtered count is not used for the search-bar threshold.

The useSearchResults hook at line 554 also receives the raw data array. The clear-input effect in src/hooks/useSearchResults.ts:34-39 checks data.length against the threshold, so it too never fires while pending-DELETE rows inflate the count. However, useSearchResults must continue to receive the full data array because the filteredData it returns drives SelectionListWithModal, and pending-DELETE rows must stay in the rendered list so users can dismiss delete errors via onDismissError.

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

1. Fix shouldShowSearchBar in WorkspaceMembersPage.tsx — change line 590 to use the existing memberCount variable (already filtered at line 583) instead of data.length:

- const shouldShowSearchBar = data.length >= CONST.STANDARD_LIST_ITEM_LIMIT;
+ const shouldShowSearchBar = memberCount >= CONST.STANDARD_LIST_ITEM_LIMIT;

2. Fix the clear-input threshold in useSearchResults — the hook needs a separate count parameter so the caller can pass the visible (pending-DELETE-excluded) count while still passing the full list for rendering. Add an optional visibleCount parameter and use it in the clear-input effect:

- function useSearchResults<TValue>(data: TValue[], ...): [string, ...] {
+ function useSearchResults<TValue>(data: TValue[], ..., visibleCount?: number): [string, ...] {
   ...
   useEffect(() => {
-    if (data.length < CONST.STANDARD_LIST_ITEM_LIMIT) {
+    if ((visibleCount ?? data.length) < CONST.STANDARD_LIST_ITEM_LIMIT) {
       setInputValue('');
     }
   }, [data.length, ...]);

Then at the WorkspaceMembersPage.tsx call site (line 554), pass memberCount as visibleCount:

- const [inputValue, setInputValue, filteredData] = useSearchResults(data, filterMember, sortMembers, rolePreFilter);
+ const [inputValue, setInputValue, filteredData] = useSearchResults(data, filterMember, sortMembers, rolePreFilter, memberCount);

This keeps the full data array flowing into filteredData and then into SelectionListWithModal, preserving pending-DELETE rows for error dismissal, while the clear-input effect responds to the correct visible count.

3. Audit sibling pages — apply the same shouldShowSearchBar fix to BaseDomainMembersPage.tsx:211 and WorkspacesListPage.tsx:650-653, changing their data.length >= CONST.STANDARD_LIST_ITEM_LIMIT guards to use their respective pending-DELETE-filtered counts. Pass the filtered count as visibleCount to their useSearchResults calls for the same reason.

4. No native/web split needed; the fix is in shared code and resolves both Android and Web reports.

What alternative solutions did you explore? (Optional)

Filtering inside useSearchResults itself (removing pending-DELETE entries before length checks and before returning filteredData) was considered but rejected — the hook is generic over TValue and has no knowledge of pendingAction. More importantly, filteredData feeds directly into SelectionListWithModal, which needs pending-DELETE rows present so users can invoke onDismissError to dismiss failed-delete error states. Filtering there would silently drop those rows and block error recovery.