Observer holding on to old queryClient when client changes in QueryClientProvider

[tonyxiao]

Describe the bug

In our app we allow user to switch between workspaces, and when they do we want an entirely different set of query cache / query client combo to isolate the data between workspaces. However simply changing the client provided to QueryClientProvider does not cause queries to refetch. Even manually calling refetch doesn't fully resolve the issue because the Observer has a constant reference to the previous QueryClient that does not update.

See trpc/trpc#4153 (comment) for additional context

Your minimal, reproducible example

https://github.com/tonyxiao/next-turbopack-example/blob/main/packages/app1/app/debug/page.tsx

Steps to reproduce

1. Type into the slug field to cause queryClient to change
2. Notice that value of res.data stays the same

Expected behavior

I would expect 1) All the queries to refetch and 2) Either new observers to be created or for the existing observer to update their query client reference.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

All platforms

Tanstack Query adapter

None

TanStack Query version

4.29.7

TypeScript version

No response

Additional context

No response

[artem-malko]

Looks like a duplicate of #5443 @tonyxiao check this issue. I'm not sure, but who knows)

[TkDodo]

@artem-malko I don't think they are related.

@tonyxiao I don't think creating a new QueryClient inside useMemo is a good idea. useMemo is a perf optimization, not a semantic guarantee that the code will only be executed if the dependencies changes. So you can wind up with random new QueryClients even though you didn't expect them to be recreated. It's a dangerous path.

I also don't think we support swapping out queryClients like that. What you can do is just call queryClient.clear() to clean it when a workspace switch happens. Otherwise, what also works is to add the workspaceId to all your Queries as a QueryKey, like:

['workspace', id, 'user', id]

etc to avoid sharing data. This is what we do, so that we can keep data cached between workspace switches.

Nuclear option would be to assign a key to your component above the one that creates the QueryKey to have react un-mount and re-mount the whole tree. Like:

<MyApp key={workspaceId}>

This would then create a new QueryClient, and there wouldn't be any references of old ones left.

[tonyxiao]

Got it, thanks so much for the workaround recommendations too. We are using tanstack/query through trpc so there is not as much ability to manually control the query key unfortunately. (see trpc/trpc#4153)

What about using queryClient.invalidateQueries to invalidate all? clear would only get rid of the cache but wouldn't cause any refetch to happen right?

Finally if swaping queryClient is not a supported behavior in the QueryClientProvider, could we add either a warning or throw an error in the provider component?

[tonyxiao]

Oh side note, is there an alternative to useMemo you'd recommend that does have the semantic guarantee? A cursory search found this repo (https://github.com/alexreardon/use-memo-one) but it doesn't seem to be maintained.

[TkDodo]

What about using queryClient.invalidateQueries to invalidate all? clear would only get rid of the cache but wouldn't cause any refetch to happen right?

invalidate doesn't remove though. it only refetches active queries and marks others as stale. What you are likely looking for is queryClient.resetQueries to reset all back to their initial state, then trigger a refetch of active observers.

Finally if swaping queryClient is not a supported behavior in the QueryClientProvider, could we add either a warning or throw an error in the provider component?

if you want to contribute a dev only warning, sure, as long it doesn't affect bundle size of production builds.

Oh side note, is there an alternative to useMemo you'd recommend that does have the semantic guarantee?

useState: https://tkdodo.eu/blog/use-state-for-one-time-initializations

[gaearon]

I also don't think we support swapping out queryClients like that.

Just wanted to note this really is not very good; a React component is expected to support handling a change to its props gracefully. If this is really not supported, it's worth warning about in console — but also it would be great to make this supported.

[gaearon]

For posterity, the solution we went with was placing a queryClient in state for the tree below, and forcing a remount with key when the user ID changes so that the entire tree below reinitializes with the new client (bluesky-social/social-app#3333). This avoids this problem at the cost of remounting the UI (which for switching users is probably a good idea anyway — to clear out any lingering state — not sure about switching workspaces).

[luixo]

I want to reopen the discussion on memoization of client in Observer.

Currently, changing a queryClient will result in mix of options from and old client (the one Observer was mounted with) and any rerendered client.

As queryClient in Observer is only used to get cache, all the bugs should be quite similar to the one in this issue.

With a simple fix there seem to be no breaking change* and the bug is eliminated.

// packages/query-core/src/queryObserver.ts#136
setClient(client: QueryClient): void {
  this.#client = client
}
// packages/react-query/src/useBaseQuery.ts#95
React.useEffect(() => {
  observer.setClient(client)
}, [client, observer])

*test 'should be able to persist into multiple clients' in react-query-persist-client fails because restoring happens in original client which is immediately swapped (I suppose that's a bug in tests though a subject to discuss)

[luixo]

@TkDodo can we get back to this?
Should I open a PR to fix that, do you agree with the general approach?

[TkDodo]

@luixo yeah we can do that; there’s been a change recently where the client is now also forwarded to the query living in the cache, so we should really properly propagate it down. That likely means:

// packages/query-core/src/queryObserver.ts#136
setClient(client: QueryClient): void {
  this.#client = client
  this.#currentQuery.setClient(client)
}

might even be worth removing this.#client from the observer and always using the one from the currentQuery?

if you make a PR with some tests, we can see if that works.

// packages/react-query/src/useBaseQuery.ts#95

note: don’t forget useQueries.