fix(solid-query): attach 'useQueries' through the provider's hydration channel - #11186
Conversation
Sorry, something went wrong.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 31b0fc73-cce1-4855-b023-b7ac53a93a8e You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file. Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. ❤️ ShareComment @coderabbitai help to get the list of available commands. |
Sorry, something went wrong.
MILLERMARRU
left a comment
There was a problem hiding this comment.
I checked this against the pre-PR QueryClientProvider.tsx on the solid-query-v6-pre branch and the existing code comment literally says the effect never fires for a fresh client mount. That's fine as long as nothing waits on the channel, but this PR makes useQueries wait on it via coordinator.whenQueryPrimed. Without the replayProbe addition, a fresh client-only mount (no SSR at all) would leave every useQueries call stuck waiting for entries that will never arrive. The executor-runs-synchronously trick for distinguishing a real fresh-mount Promise from a replayed hydration signal matches the same pattern already used by useBaseQuery, so it's consistent with the existing convention rather than a new one. The added StreamApp fixture query that settles last but hydrates in the shell is a good regression test for the actual race being fixed.
Sorry, something went wrong.
🎯 Changes
useQueries never got the hydration coordination that #11168 added to useBaseQuery. It builds its own QueriesObserver and subscribes from an effect, so a component that hydrates before its dehydrated entries have arrived on the SSR stream attaches to a cold cache and refetches on mount, even for data that is well inside staleTime.
The subscription now goes through the same coordinator. With a provider in place, useQueries attaches once every one of its queries has been primed, or once the channel reports itself done. One QueriesObserver covers all of the queries, so it can only attach when the last one is ready. QueryClientProvider closes the channel right away on a fresh client mount, detected with the same Promise executor probe useBaseQuery uses, so an app without SSR never waits.
For the test, the streaming fixture gains a useQueries in the shell whose query settles after the slow boundary, so its entry only rides the final flush. Before the change it refetches at shell hydration.
Fixes #11185
✅ Checklist
Local verification: vitest run on solid-query (330 tests), solid-query-persist-client and solid-query-devtools, all green with no type errors; eslint and prettier clean.
🚀 Release Impact