82585: Web - Search - Search list shows blank recent searches#84653
82585: Web - Search - Search list shows blank recent searches#84653marcaaron merged 9 commits intoExpensify:mainfrom
Conversation
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
|
@eVoloshchak Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
@marcaaron Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
@eVoloshchak Can u review this PR.Thanks |
JmillsExpensify
left a comment
There was a problem hiding this comment.
Product behavior outlined in testing steps LGTM
@abbasifaizan70, there is still a delay after the step 6, search results are not shown immediately, they pop up after a few seconds Screen.Recording.2026-03-16.at.16.43.41.mov |
Screen.Recording.2026-03-18.at.3.09.59.AM.mov@eVoloshchak tried to fix this delay. Can you now do testing on your side? |
|
This did reduce the delay (to the point where it's barely noticeable, but I wonder if we can get rid of it completely)
Screen.Recording.2026-03-18.at.20.27.16.movScreen.Recording.2026-03-18.at.20.25.29.mov |
|
@eVoloshchak The slight delay and rearrangement of the Recent Searches list is actually expected behavior due to how the backend processes rapid, consecutive search requests. When you click through the 4 Insights tabs quickly, the client fires off 4 separate Search API requests in rapid succession. Because these are asynchronous network requests, they do not necessarily complete in the exact order they were sent. The RECENT_SEARCHES Onyx key is updated by the server's response. As each of the 4 responses trickles back to the client at slightly different times, the server assigns them a timestamp. Since the responses arrive out of order, the timestamps are generated out of order. When you press Cmd+K, the Search Router reads from RECENT_SEARCHES and sorts them by timestamp. Because the timestamps from the server were generated out of order due to network latency, the list appears to 'rearrange' as the final responses arrive and the list re-sorts itself based on the new timestamps. The only way to completely eliminate this would be to implement an optimistic, client-side update to RECENT_SEARCHES the moment an Insights tab is clicked (before the API request is even sent), so the client can lock in the exact chronological order of the clicks. However, that is a much larger architectural change to how Search history is tracked, and falls outside the scope of fixing the visual gap/duplicate key issue in this PR. |
|
Conflicts here. Are we close on this one? Thanks! |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppScreen.Recording.2026-03-26.at.21.27.13.movAndroid: mWeb ChromeScreen.Recording.2026-03-26.at.21.24.55.moviOS: HybridAppScreen.Recording.2026-03-26.at.21.17.19.moviOS: mWeb SafariScreen.Recording.2026-03-26.at.21.19.19.movMacOS: Chrome / SafariScreen.Recording.2026-03-26.at.21.13.40.mov |
|
@MelvinBot, resolve conflicts |
|
To have me resolve the conflicts, the PR author or assignee (
|
# Conflicts: # src/components/Search/SearchAutocompleteList.tsx
|
@eVoloshchak solved conflicts. |
|
🚧 @marcaaron has triggered a test Expensify/App build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/marcaaron in version: 9.3.50-0 🚀
Bundle Size Analysis (Sentry): |
|
I have failed to help you. I let you down and for that I am sorry. Please try again later. This may be due to a Claude outage (check here). Failure details: https://github.com/Expensify/Expensify/actions/runs/23647048496 |
Explanation of Change
Updated recent-search list item keys to use the unique Onyx recentSearchHash instead of timestamp, preventing duplicate key collisions when multiple searches are saved quickly.
Memoized styledRecentReports and sections with useMemo so hook dependencies stay stable and ESLint warnings are resolved without changing search router behavior.
Fixed Issues
$ #82585
PROPOSAL: #82585 (comment)
Tests
Offline tests
Same as tests.
QA Steps
Same as tests.
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectioncanBeMissingparam foruseOnyxtoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Screen.Recording.2026-03-13.at.3.07.54.AM.mov
Android: mWeb Chrome
Screen.Recording.2026-03-13.at.3.09.38.AM.mov
iOS: Native
Screen.Recording.2026-03-12.at.4.00.13.AM.mov
iOS: mWeb Safari
Screen.Recording.2026-03-12.at.4.03.26.AM.mov
MacOS: Chrome / Safari
Screen.Recording.2026-03-10.at.3.58.09.AM.mov