Dehydrate stale fetching queries?

[erjohnms]

I am trying out react-router v7 + react-query and following the docs for SSR and hydrating the query cache on the client. I additionally dehydrate pending queries and as the data becomes available it streams to the client. I love it.

In addition to this, I wanted to introduce server-side caching of the query cache. I'm using @tanstack/query-async-storage-persister with, redis.

Once I introduce server-side storage, I run into a problem around stale queries.

What I think I want is:
Loader query client starts with the persisted cache
If queries are stale, return the stale cache for client hydration but also initiate a fetch server side
Client renders with dehydrated (stale) query cache and does not re-fetch
Server query client finishes its fetch
Server query client saves the result into server-side cache
New results are streamed to the client
Client query client gets refreshed with new results

Essentially identical to how hydrating pending queries works, except that I got to first render with stale data.

However, this doesn't work the way I expected because dehydrateQuery only saves the promises for pending queries, not fetching queries

so, what actually happens in my circumstance is that BOTH the server and the client will initiate fetches on stale queries that came from my persisted server cache.

I'm curious if this dehydrateQuery function I linked to is either just missing this feature, I'm supposed to implement this idea a different way and not just dehydrate the query client, or if this is deliberate and what I am trying to do is considered an anti-pattern for reasons I don't yet understand?

[TkDodo]

However, this doesn't work the way I expected because dehydrateQuery only saves the promises for pending queries, not fetching queries

I don’t think this is a case we currently support. We have that guard because pending queries are excluded from hydration per default, so this feature is opt-in. Otherwise, background refetches would also persist the promise, as hydration is also used for other use-cases (like the persist plugins).

[erjohnms]

For those that come across this thread, I've been testing the below patch in our setup, and it's been working well. But keep in mind that the only place I dehydrate pending/fetching queries is when passing the query client in my Remix loaders to my routes. In other cases, such as persisting queries to Redis, I'm awaiting the promises before dehydrating. So, if you have other uses cases as TkDodo mention's above, YMMV.

diff --git a/build/modern/hydration.js b/build/modern/hydration.js
index 6c25c664ba5d7f0b1b5e6fb95067930543bfc140..5bff8badc113b4b82ed99ce7f694f9026b5ce575 100644
--- a/build/modern/hydration.js
+++ b/build/modern/hydration.js
@@ -20,7 +20,7 @@ function dehydrateQuery(query, serializeData, shouldRedactErrors) {
     },
     queryKey: query.queryKey,
     queryHash: query.queryHash,
-    ...query.state.status === "pending" && {
+    ...query.state.fetchStatus === "fetching" && {
       promise: query.promise?.then(serializeData).catch((error) => {
         if (!shouldRedactErrors(error)) {
           return Promise.reject(error);