[Due for payment 2026-04-23] [$250] Cmd+K search misses workspace members and blocks selection during loading

[MelvinBot]

Slack thread: https://expensify.slack.com/archives/C05LX9D6E07/p1775170058986479

Bug 1: Cmd+K fails to show workspace members you haven't recently chatted with

Expected: When searching Cmd+K, workspace members should always appear in results immediately from locally cached personalDetails.

Actual: Sometimes searching for a workspace member you haven't chatted with recently returns other results instead. After ~300ms, the server search backfills and the person appears — but they should have been found locally.

Root cause analysis

Frontend — hard cap of 20 results starves personalDetails slots:

getValidOptions (src/libs/OptionsListUtils/index.ts) calculates:

maxPersonalDetailsElements = Math.max(20 - recentReportOptions.length - workspaceChats.length - ..., 0)

If the search term matches 20+ reports, zero personalDetails slots remain. A workspace member with no existing DM report only exists in the personalDetails list and becomes completely invisible. The server search then returns their DM report 300ms later, making them appear — exactly matching the reported behavior.

Additional contributing factors:

• Asymmetric search fields — report search checks report.text + report.login, while personalDetail search also checks displayName and login-without-domain. A name match on personalDetails can be invisible if report search consumed all 20 slots.
• Over-aggressive deduplication — filteredPersonalDetailsOfRecentReports removes personalDetails entries sharing a login with any recent report, even if that report didn't match the search query.

Backend — OpenApp personalDetails query can miss workspace members:

The OpenApp command builds personalDetails via a UNION query (Account::runPersonalDetailsQuery). This can miss members when:

1. disableAttendeeList filter — policies with this setting exclude ALL their members from the personalDetails response.
2. Race condition with new members — if a member was just added and the sharedNameValuePairs row hasn't propagated, they're missing.
3. Parallel thread failures — collectSearchTodosData runs in parallel threads merging into personalDetailsList, with catch blocks that silently swallow exceptions.

Bug 2: Cannot select a Cmd+K result until the loading spinner finishes

Expected: When a search result appears in Cmd+K, it should be immediately selectable.

Actual: After finding a chat in Cmd+K results, the user cannot select it until a loading spinner completes. This creates unnecessary friction — if the result is already displayed, it should be interactive.

Platforms

All platforms (Cmd+K / Ctrl+K search).

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022041502286489838422
• Upwork Job ID: 2041502286489838422
• Last Price Increase: 2026-04-07

[MelvinBot]

Proposal

What is the root cause of that problem?

Bug 1 — Cmd+K misses workspace members:

The slot-starvation mechanism described in the issue body is correct, but the cap is 50 (MAX_SELECTION_LIST_PAGE_LENGTH at src/CONST/index.ts:6321), not 20.

At src/libs/OptionsListUtils/index.ts:2667:

maxPersonalDetailsElements = Math.max(maxElements - recentReportOptions.length - workspaceChats.length - (!selfDMChat ? 1 : 0), 0)

When recentReportOptions + workspaceChats >= 50, personalDetails slots drop to zero. Workspace members without an existing DM report only exist in the personalDetails list and become invisible.

Two compounding factors:

1. Asymmetric search — report matching (lines 2509–2523) checks text, login, alternateText, subtitle, policyName, and participant names. PersonalDetails matching (lines 2660–2663, 3023–3028) only checks displayName and login. Generic terms match far more reports.
2. Over-aggressive dedup — filteredPersonalDetailsOfRecentReports (line 3038–3041) removes any personalDetail whose login matches ANY recentReport's login, even if that report didn't match the search query. This is a second exclusion layer applied after getValidOptions returns.

Bug 2 — Cannot select results during loading:

The server search spinner (isSearchingForReports) does not block list interaction — it only shows a spinner in the text input (SearchAutocompleteInput.tsx:228). selectRow in BaseSelectionListWithSections.tsx:159–180 does not check any loading state.

The actual blocking comes from two cold-start loading gates in SearchAutocompleteList.tsx:

1. isRecentSearchesDataLoaded (lines 468, 519–528) — when Onyx hasn't loaded RECENT_SEARCHES, the entire list is replaced by a non-interactive OptionsListSkeletonView.
2. areOptionsInitialized (lines 407–431) — when the option list isn't built yet, recent chats render as zero data items with a skeleton header.

On native, DeferredSearchAutocompleteList (index.native.tsx:14–38) adds an additional skeleton phase via React.startTransition.

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

Bug 1 fix — guarantee minimum personalDetails slots:

In getValidOptions at src/libs/OptionsListUtils/index.ts:2667, change the formula to reserve a minimum number of personalDetails slots (e.g., 5–10) regardless of how many reports match. Something like:

const MIN_PERSONAL_DETAILS_SLOTS = 5;
const maxPersonalDetailsElements = maxElements
    ? Math.max(maxElements - recentReportOptions.length - workspaceChats.length - (!selfDMChat ? 1 : 0), MIN_PERSONAL_DETAILS_SLOTS)
    : undefined;

This ensures workspace members always have a chance to appear. The total result count may slightly exceed maxElements, but that's preferable to invisible members.

Additionally, fix filteredPersonalDetailsOfRecentReports (line 3038) to only exclude personalDetails whose corresponding report actually matched the search, rather than excluding based on all recent reports unconditionally.

Bug 2 fix — render available results immediately:

In SearchAutocompleteList.tsx, instead of replacing the entire list with a skeleton when isRecentSearchesDataLoaded is false or areOptionsInitialized is false, render whatever results are already available alongside a loading indicator. The skeleton should be a fallback only when there are truly zero items to show, not a gate that blocks all interaction.

What alternative solutions did you explore? (Optional)

For Bug 1, an alternative is increasing MAX_SELECTION_LIST_PAGE_LENGTH from 50 to a higher value. However, this doesn't solve the fundamental problem — it just raises the threshold. The minimum-slots approach is more robust.

For Bug 2, another option is to pre-load RECENT_SEARCHES and initialize options eagerly at app startup rather than lazily when Cmd+K opens. This would eliminate the cold-start skeleton entirely but adds to initial app load time.

---

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

[melvin-bot]

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