[$250] Web - Search - Search list shows blank recent searches

[jponikarchuk]

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: 9.3.20-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/test-runs/TR-5426/folder/13176964/41237752/1193286463?issue_type=jira
Email or phone of affected tester (no customers): josdnjsodijsondjsoij@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Create a new account.
3. Create a workspace.
4. Go to Reports tab.
5. Open each Insights tab (Spend over time, Top spenders, Top categories, Top merchants) quickly and go back to Inbox.
6. Open search router on the top right.

Expected Result:

Search list will show each recent searches.

Actual Result:

Search list will show each recent searches.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abbasifaizan70

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022028956991497423106
• Upwork Job ID: 2028956991497423106
• Last Price Increase: 2026-03-03

[abbasifaizan70]

🚨 Edited by proposal-police: This proposal was edited at 2026-03-04 21:33:57 UTC.

Proposal

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

Search list opens with an unexpected blank vertical gap between the Recent searches heading and the first recent-search row.

---

What is the root cause of that problem?

The Recent searches rows use timestamp as keyForList. When multiple searches are saved rapidly, timestamps can collide, which creates duplicate keys in the list. Duplicate keys can cause unstable row reuse and leave a visible blank gap in the section.

App/src/components/Search/SearchAutocompleteList.tsx

Lines 266 to 291 in 3a6fe5c

	const sortedRecentSearches = Object.values(recentSearches ?? {}).sort((a, b) => localeCompare(b.timestamp, a.timestamp));
	const recentSearchesData = sortedRecentSearches?.slice(0, 5).map(({query, timestamp}) => {
	const searchQueryJSON = buildSearchQueryJSON(query);
	return {
	text: searchQueryJSON
	? buildUserReadableQueryString({
	queryJSON: searchQueryJSON,
	PersonalDetails: personalDetails,
	reports,
	taxRates,
	cardList: allCards,
	cardFeeds: allFeeds,
	policies,
	currentUserAccountID,
	autoCompleteWithSpace: false,
	translate,
	feedKeysWithCards,
	})
	: query,
	singleIcon: expensifyIcons.History,
	searchQuery: query,
	keyForList: timestamp,
	searchItemType: CONST.SEARCH.SEARCH_ROUTER_ITEM_TYPE.SEARCH,
	};
	});

---

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

Use the Onyx entry key (recentSearchHash) as keyForList for recent-search rows. The hash is unique per saved search and avoids collisions during fast tab switching.

App/src/components/Search/SearchAutocompleteList.tsx

Lines 266 to 291 in 3a6fe5c

	const sortedRecentSearches = Object.values(recentSearches ?? {}).sort((a, b) => localeCompare(b.timestamp, a.timestamp));
	const recentSearchesData = sortedRecentSearches?.slice(0, 5).map(({query, timestamp}) => {
	const searchQueryJSON = buildSearchQueryJSON(query);
	return {
	text: searchQueryJSON
	? buildUserReadableQueryString({
	queryJSON: searchQueryJSON,
	PersonalDetails: personalDetails,
	reports,
	taxRates,
	cardList: allCards,
	cardFeeds: allFeeds,
	policies,
	currentUserAccountID,
	autoCompleteWithSpace: false,
	translate,
	feedKeysWithCards,
	})
	: query,
	singleIcon: expensifyIcons.History,
	searchQuery: query,
	keyForList: timestamp,
	searchItemType: CONST.SEARCH.SEARCH_ROUTER_ITEM_TYPE.SEARCH,
	};
	});

const sortedRecentSearches = Object.entries(recentSearches ?? {}).sort(([, firstRecentSearch], [, secondRecentSearch]) => localeCompare(secondRecentSearch.timestamp, firstRecentSearch.timestamp));

const recentSearchesData = sortedRecentSearches?.slice(0, 5).map(([recentSearchHash, {query}]) => {
    const searchQueryJSON = buildSearchQueryJSON(query);
    return {
        text: searchQueryJSON
            ? buildUserReadableQueryString({
                  queryJSON: searchQueryJSON,
                  PersonalDetails: personalDetails,
                  reports,
                  taxRates,
                  cardList: allCards,
                  cardFeeds: allFeeds,
                  policies,
                  currentUserAccountID,
                  autoCompleteWithSpace: false,
                  translate,
                  feedKeysWithCards,
              })
            : query,
        singleIcon: expensifyIcons.History,
        searchQuery: query,
        keyForList: recentSearchHash,
        searchItemType: CONST.SEARCH.SEARCH_ROUTER_ITEM_TYPE.SEARCH,
    };
});

---

Demo

Screen.Recording.2026-03-05.at.2.20.02.AM.mov

[melvin-bot]

Triggered auto assignment to @heyjennahay (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

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

After quickly opening each Insights tab (Spend over time, Top spenders, Top categories, Top merchants) and returning to the Inbox, the search router shows a loading skeleton instead of the user's recent searches. The recent search data is available in Onyx, but the UI blocks it behind an unrelated loading condition.

What is the root cause of that problem?

SearchAutocompleteList gates its entire rendered output on two conditions at SearchAutocompleteList.tsx:416-417:

const isRecentSearchesDataLoaded = !isLoadingOnyxValue(recentSearchesMetadata);
const isLoading = !isRecentSearchesDataLoaded || !areOptionsInitialized;

When isLoading is true, the component returns an OptionsListSkeletonView (lines 419-427), hiding everything — including recent searches that are already loaded from Onyx.

The areOptionsInitialized flag comes from useOptionsList(), which internally starts with useState(false) at OptionListContextProvider.tsx:307 and only syncs to true after a useEffect fires. This means any mount or remount of SearchAutocompleteList shows the skeleton for at least one render cycle, regardless of whether the provider has already initialized.

Recent searches come directly from the ONYXKEYS.RECENT_SEARCHES NVP (line 154) and have no dependency on the options list (reports/personal details). The component already handles the uninitialized-options case at lines 166-169 by falling back to defaultListOptions (empty arrays), so it can render safely without options. Despite this, the loading gate at line 417 blocks the entire list — including the independent recent searches section — until options initialize.

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

File: src/components/Search/SearchAutocompleteList.tsx

Remove areOptionsInitialized from the loading gate so the list renders as soon as recent searches are loaded:

 const isRecentSearchesDataLoaded = !isLoadingOnyxValue(recentSearchesMetadata);
-const isLoading = !isRecentSearchesDataLoaded || !areOptionsInitialized;
+const isLoading = !isRecentSearchesDataLoaded;

This is safe because:

1. Recent searches come directly from Onyx, not from the options list
2. Lines 166-169 already handle !areOptionsInitialized by returning defaultListOptions (empty arrays) — the options-dependent sections (recent reports/chats, autocomplete suggestions) gracefully degrade to empty until options initialize
3. The SelectionListWithSections at line 431 has showLoadingPlaceholder set, so if the options-dependent sections are empty, it will show an appropriate placeholder for those sections while recent searches remain visible

Note: The existing proposal from abbasifaizan70 identifies the correct root cause and fix direction, but references outdated code locations — the shouldShowList variable in SearchRouter.tsx no longer exists. The loading gate has since been moved into SearchAutocompleteList.tsx at the lines referenced above.

Detailed Investigation

Evidence Chain

1. Loading gate blocks the full list — SearchAutocompleteList.tsx:416-427: When isLoading is true (either recent searches not loaded OR options not initialized), the entire component returns OptionsListSkeletonView. Recent searches at line 340 never get a chance to render.

2. Recent searches are independent of options — SearchAutocompleteList.tsx:154: const [recentSearches, recentSearchesMetadata] = useOnyx(ONYXKEYS.RECENT_SEARCHES) loads directly from Onyx with no dependency on the options list.

3. Options fallback already exists — SearchAutocompleteList.tsx:166-169: if (!areOptionsInitialized) { return defaultListOptions; } returns empty arrays so the component can render safely without initialized options.

4. useOptionsList always starts false — OptionListContextProvider.tsx:307: useState(false) for areInternalOptionsInitialized means every mount starts showing the skeleton, even if the provider has already initialized options.

5. OptionListContextProvider doesn't reset during navigation — AuthScreens.tsx:516: The provider is mounted at the AuthScreens level and persists across all navigation. resetOptions() is only called from TroubleshootPage.tsx:78.

6. Quick Insights navigation is safe — SearchTypeMenu.tsx:141: Insights tabs navigate within the same SearchFullscreenNavigator. Search API calls update ONYXKEYS.COLLECTION.SNAPSHOT, not ONYXKEYS.COLLECTION.REPORT, so the option list data is unaffected.

Relevant Code

• src/components/Search/SearchAutocompleteList.tsx:154 — Recent searches Onyx subscription
• src/components/Search/SearchAutocompleteList.tsx:165-169 — Options initialization check with fallback
• src/components/Search/SearchAutocompleteList.tsx:340-342 — Recent searches section generation
• src/components/Search/SearchAutocompleteList.tsx:416-427 — The loading gate (root cause)
• src/components/OptionListContextProvider.tsx:286,307 — areOptionsInitialized ref/state propagation

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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