Describe the bug
When the user's searchProvider setting is npm (instead of the default algolia), several pages experience SSR hydration errors and broken behavior.
Affected routes
/search?q=vue — hydration error + brief flash of correct results followed by a "no results" screen/settings — hydration error- Likely also
/~[username] and /org/[orgname] routes (any route using search composables)
Additional context
Root cause (issue is created post MR creation 😅 )
The server always fetches search data using the default provider (algolia), producing an SSR cache key like search:algolia:vue. When the client hydrates with searchProvider = 'npm', it looks for search:npm:vue in the payload — which doesn't exist. This cache key mismatch causes useLazyAsyncData to miss the SSR cache, triggering a client-side refetch and hydration errors.
Logs
## Steps to reproduce
1. Go to `/settings`, change the search data source to **npm**
2. Navigate directly (via URL bar) to `/search?q=vue`
3. **Observe:** hydration errors in console; search results flash then disappear, replaced by "no results"
4. Navigate directly to `/settings`
5. **Observe:** hydration error in console
Describe the bug
When the user's
searchProvidersetting isnpm(instead of the defaultalgolia), several pages experience SSR hydration errors and broken behavior.Affected routes
/search?q=vue— hydration error + brief flash of correct results followed by a "no results" screen/settings— hydration error/~[username]and/org/[orgname]routes (any route using search composables)Additional context
Root cause (issue is created post MR creation 😅 )
The server always fetches search data using the default provider (
algolia), producing an SSR cache key likesearch:algolia:vue. When the client hydrates withsearchProvider = 'npm', it looks forsearch:npm:vuein the payload — which doesn't exist. This cache key mismatch causesuseLazyAsyncDatato miss the SSR cache, triggering a client-side refetch and hydration errors.Logs