Is there ever a reason for cacheTime !== Infinity for SSR?

[JacobLey]

I am using React Query with Next.JS, very similar to the provided example: https://react-query.tanstack.com/guides/ssr (prefetch + hydrate)

I also have a test script that boots up my NextJS server, pings it with a few requests, then shuts down. I ran into an issue that the test process never exited, and eventually landed on the issue being similar to Jest.

My understanding is that the cache is used to dedupe requests and provide a source-of-truth for a given queryKey. Given that SSR lifecycle for a given QueryClient should only be a single request

Create a new QueryClient instance for each page request. This ensures that data is not shared between users and requests.

the cache should be "permanent" for the lifecycle of the request (realistically a few milliseconds) and then cleaned up (probably through NodeJS's default garbage collection)

So the obvious solution to me is to just set cacheTime=Infinity for all server-side QueryClients. (All the time, regardless of test/production environment/framework)

So to get to my question, is there ever a reason for cacheTime to not be Infinity during SSR? Are there any supported use case server-side query clients over a long period of time, or multiple sessions/requests?

It seems like a benefit to set Infinity (by default) server-side for cacheTime?

[JacobLey]

I'm mostly interested in justifying a PR to set cacheTime=Infinity as default for SSR, if it is an improvement 100% of the time.

Thinking of other use cases for this library, I suppose a queryClient could be used to prefetch/cache database lookups in a server environment like Express. But even then I would expect the cache to follow the same Infinity rules (unique client per-request, no automatic cache invalidation during lifecycle of request)...

Perhaps it also works as some global backend cache... but the React part of this package's name seems to really discourage that 😉 and really a tool like Redis is better for that.