"No QueryClient set" when upgrading from 3.12.0 to 3.12.1

[hmaurer]

Describe the bug

When upgrading from [email protected] to [email protected], getting the following error in the browser console:

QueryClientProvider.js:36 Uncaught (in promise) Error: No QueryClient set, use QueryClientProvider to set one
    at useQueryClient2 (QueryClientProvider.js:36)
    at ReactQueryDevtoolsPanel2 (devtools.js:267)

To Reproduce

git clone [email protected]:5ae9c1e18b571bafe17da22775b28329.git react-query-1936
cd react-query-1936
npm install
npm run dev

Open the dev server in the browser. You should see a blank page and observe the following error in the browser console:

QueryClientProvider.js:36 Uncaught (in promise) Error: No QueryClient set, use QueryClientProvider to set one
    at useQueryClient2 (QueryClientProvider.js:36)
    at ReactQueryDevtoolsPanel2 (devtools.js:267)

Now change the version of react-query in package.json to 3.12.0, run npm install and re-start the dev server (interrupt npm run dev and run it again). You should now see App on the page and no error in the console.

[TkDodo]

Hm, I have seen something similar on stackoverflow: https://stackoverflow.com/questions/66553816/react-query-is-not-working-with-a-project-bootstrapped-with-vite

what 3.12.1 did was turn off an (undocumented) context-sharing feature where the QueryClient was attached to the window, which caused troubles for microfrontends mounted multiple times on the same page. The feature is now opt-in, see: https://react-query.tanstack.com/reference/QueryClientProvider

The QueryClient is now retrieved solely via react-context. If the <ReactQueryDevtools> are inside the <QueryClientProvider> in the react component tree, I don't see how the client could not be found :/

[hmaurer]

@TkDodo Thanks for your response! I should have specified that I am indeed using Vite. That said, ReactQueryDevtools is included under a QueryClientProvider (literally all I did was bumping the version from 13.12.0 to 13.12.1; I had no issues before).

[TkDodo]

can you create a repo that I can check out that reproduces the issue? I have no idea what vite is or how it works 😅 .

you can also try to turn on context sharing via the prop on the QueryClientProvider - that should "restore" the behaviour of 3.12.0. But again, we are just using react-context now :(

[hmaurer]

@TkDodo I've added a reproduction to the original post! And I tried turning on context sharing but it does not appear to solve the issue.

[TkDodo]

Interesting: it works fine in Brave, but not in Chrome or Firefox

never mind that. cached service worker was showing the wrong app 😅

[TkDodo]

it seems that the react-query-devtools come with their own copy of react-query, and that they done use a different context or so. I have to admit that I don't quite understand how this bundling works, or how vite differs from create-react-app or webpack...

[hmaurer]

@TkDodo do you think this is an issue that should be reported to Vite instead? I can't quite tell if react-query is doing something wrong or if there's an issue with VIte's pre-bundling strategy. And thanks again for taking the time to look into this!

[TkDodo]

it would be at least interesting to ask there, because it seems to work fine with other bundlers

[OliverwengFiltered]

we have the same issue which prevent us from upgrading react-query to latest version

[TkDodo]

@OliverwengFiltered Are you also using vite?

[michalHT]

I have the same issue in two projects: one using parcel and the other with a custom webpack config.

[TkDodo]

@tannerlinsley can you maybe shed some light on how the devtools communicate with react-query?

[michalHT]

Oh, not sure if it matters, but I forgot to mention I am not using react-query-devtools.

[TkDodo]

Oh, not sure if it matters, but I forgot to mention I am not using react-query-devtools.

yes, that's fine. the react-query-devtools package is v2 - v3 has them "built in"

[hmaurer]

@TkDodo I think you are onto something with there being two copies of react-query; at least that's what seems to be happening with Vite. But perhaps this is due to how the devtools sub-package is constructed?

[TkDodo]

But perhaps this is due to how the devtools sub-package is constructed?

Yes, I think so, too. Remaining questions:

• why does it work with create-react-app?
• why did it work in 3.12.0 ?
• why does it not work in 3.12.1, even when adding contextSharing: true, which should have the same behaviour as 3.12.0
• How is the devtools sub-package constructed 😅

FYI, here are the relevant changes I made in 3.12.1:

v3.12.0...v3.12.1#diff-0cee58d9679ff6f79b5250cc0611ce6eaf8bc46a77416a09384ae4670adc9872R20-R67

[hmaurer]

@TkDodo Thanks for linking to the diff, I couldn't figure out how to get a diff between two versions earlier 😅 Here's my guess:

• Some dev servers (Vite, perhaps Parcel as @michalHT seems to indicate) have always bundled things in a way that creates two runtime copies of react-query. This is either a problem with these dev servers themselves (they're mishandling some legitimate pattern that react-query follows), or a problem in react-query itself (the way it's constructing the devtools sub-package is flawed). That requires further investigation / input from @tannerlinsley
• Prior to 3.12.1, the query client was shared on window, so two runtime copies of react-query didn't cause issues.
• In 3.12.1, a contextSharing option was introduced, defaulting to false. Now it'd seem like enabling context sharing would get us back to the state of things in 3.12.0 and solve the issue, but it does not. Here's the reason why: the context sharing flag is itself passed via react context, c.f. v3.12.0...v3.12.1#diff-0cee58d9679ff6f79b5250cc0611ce6eaf8bc46a77416a09384ae4670adc9872R34. And since we've two copies of react-query at runtime, we've two copies of QueryClientSharingContext. So even though contextSharing is enabled on the QueryClientProvider, the devtools are using a different copy of react-query with a different instance of QueryClientSharingContext, and so in the devtools React.useContext(QueryClientSharingContext) evaluates to false. I hope this makes sense!

[hmaurer]

To answer the questions you posed more directly, to the best of my knowledge:

why does it work with create-react-app?

Webpack bundles things in a way that doesn't create two runtime copies of react-query. I haven't tried it, though.

why did it work in 3.12.0 ?

Query client shared by default on window means that two runtime copies of react-query didn't matter (for this specific issue at least).

why does it not work in 3.12.1, even when adding contextSharing: true, which should have the same behaviour as 3.12.0

Query client is not shared by default on window, and even with contextSharing: true it's still not shared because useQueryClient uses a React context to check whether context sharing is enabled, and because we've two runtime copies of react-query the context with which we provided contextSharing: true is different than the context that useQueryClient is using (in the devtools), so it finds contextSharing: false.

How is the devtools sub-package constructed

That question remains!

[TkDodo]

that sounds spot on! Yes, I had to use another context to know if the context shared on the window should be used when getting the real context. A bit complex, but a legit solution I think. Of course, the QueryClientSharingContext also defaults to false and is never shared, so with a new copy of react-query, this will be false and therefore the window context is inaccessible.

I do think that we should not have two copies of react-query -I hope that we can somehow find a fix for packaging up the devtools to not come with their own copy :)

[hmaurer]

@TkDodo Oh I didn't realise you were the one who implemented those context sharing changes! Yeah, I think those changes were perfectly legitimate and the underlying issue here is the two copies of react-query. I am not familiar with packaging conventions at all: is the pattern used for dev-tools where you've a subdirectory with a package.json that imports files in the parent package relatively a "legitimate" one? From my perspective it's a weird pattern--I don't see what Vite could do to handle it gracefully--but I'm out of my depth here.

[piotr-cz]

I'm not sure if it helps anyone, but I've got same problem when using WMR (which prepares dev server more or less similar way as Vite does).

[csulit]

Any update on this one?

[julianklumpers]

I'm also encountering this issue when upgrading above 3.12

[TkDodo]

I have the same issue in two projects: one using parcel and the other with a custom webpack config.

So I just tried this out on a parcel (v1) project, where things work fine. We also have a product using a custom webpack config, also without issues.

[lmuller18]

This same issue is present in the Next.js example provided in this repo https://github.com/tannerlinsley/react-query/tree/master/examples/nextjs. Explicitly installing [email protected] resolves this. Does the example project need updating, or is this something that is incorrect in the 3.12.1 and up package?

[kculmback-eig]

We are experiencing this issue with ReactQueryDevtools in v3.13.3. We are using Vite. Downgrading to v3.12.0 fixes the issue.

If we remove the ReactQueryDevtools component, v3.13.3 works fine.

[Ephem]

The analysis by @hmaurer is spot on. Hydration is also affected by an identical problem which I've opened a separate issue for.

This devtools-issue is a bit more involved than the hydration one, but it stems from this line:

import { useQueryClient } from '../react'

// Should probably be:
//   import { useQueryClient } from 'react-query'

Because the reference here is relative, the whole useQueryClient-stuff including the creation of the context itself gets bundled into the devtools package, so the contexts doesn't line up. This is the root cause but was previously mitigated by the context sharing stuff.

I'm also guessing that if you build your node_modules-folder and therefor react-query, this problem might go away in some cases because that could theoretically de-duplicate these contexts.

[Ephem]

Hydration and the NextJS-example should now be fixed as well by #2121 which was released as v3.13.8.

[michalHT]

@TkDodo @Ephem I am still getting Uncaught Error: No QueryClient set, use QueryClientProvider to set one with React Query v3.13.8.
On 3.12.0 everything works fine.

client is set up like that:

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      refetchOnWindowFocus: false,
    },
    mutations: {},
  },
})

and <QueryClientProvider client={queryClient}> wraps absolutely everything.

I'm using Parcel v1.12.4.

[TkDodo]

hmm, I'm on parcel 1.12.3 and everything works for me. Can you maybe create a reproduction repo with parcel please?

[michalHT]

I wasn't able reproduce it in a simple repo, probably because my actual case is a bit more complicated. Let me try to describe it.

I'm creating a library using TSDX (rollup). This library has react-query both as a dependency and as a peerDepencency.
The library itself doesn't wrap anything with QueryClientProvider and leaves that task up to the app using it.

So in the parcel app that's using the library I have react-query as a dependency and I wrap everything with a provider as described in my previous post.

Does this setup explain why there is a problem with QueryClientProvider?

[TkDodo]

This library has react-query both as a dependency and as a peerDepencency.

and why is that please? Either the library brings react-query with it, or not. if you need it for development, use devDependency and peerDependency I'd suggest.

[michalHT]

Of course, you're right. I changed just it to devDependency, thanks.

But this still doesn't change anything with the problem at hand. On versions higher than 3.12.0 (including 3.13.9) I'm getting the error. On 3.12.0 it works fine.

[Ephem]

@michalHT Unless we missed some place in the code when fixing this bug, this error can happen for two reasons:

1. The place where the error is happening is not wrapped QueryClientProvider
2. The place where the error is happening is using a separate version of React Query from the version the QueryClientProvider is using

In your case it definitely seems like nr 2 is the culprit. Your library is pulling in and bundling one version of React Query, while the application code is using another (or just two instances of the same version). There are two ways to fix this:

1. Setup your library in a way that it doesn't bundle React Query, that is, as a peerDependency (probably a good idea to avoid including it twice in the payload anyway)
2. If you have cases where you really need to have two versions of React Query work together (like some cases with microfrontends), you can use the now documented contextSharing-option to QueryClientProvider as per the docs. Note that contextSharing will currently only work on the client and not for server rendering.

contextSharing was undocumented and not stable in 3.12.0 and the default was true. In 3.12.1 the default changed to false which is why this behaves differently between those versions but now that it's a documented feature it wont change again unless in a major.

Hope that makes sense?

[michalHT]

For different reasons I cannot go with the first approach, so I tried the second one with contextSharing set to true in the client app:

<QueryClientProvider client={queryClient} contextSharing={true}>

but it doesn't help - I'm still getting an error although the app doesn't do SSR.

[Ephem]

Aha, if contextSharing is set to true and it still doesn't work that is likely to be a bug in RQ itself. Indeed, now that I read through this thread again, @hmaurer already pointed this out:

Here's the reason why: the context sharing flag is itself passed via react context, c.f. v3.12.0...v3.12.1diff-0cee58d9679ff6f79b5250cc0611ce6eaf8bc46a77416a09384ae4670adc9872R34. And since we've two copies of react-query at runtime, we've two copies of QueryClientSharingContext. So even though contextSharing is enabled on the QueryClientProvider, the devtools are using a different copy of react-query with a different instance of QueryClientSharingContext, and so in the devtools React.useContext(QueryClientSharingContext) evaluates to false. I hope this makes sense!

While there are several things intermingled here and some of them has been fixed, I think it makes sense to reopen this issue to continue tracking that specific bug.

[fev4]

Hey everyone,

Not sure if I'm missing something silly but I get the same error with snowpack. Follow these steps for a reproduction case:

1. npx create-snowpack-app snowpack-test --template @snowpack/app-template-react --use-yarn
2. cd snowpack-text
3. yarn add react-query
4. Edit src/App.jsx and replace the contents with:

import React, { useState, useEffect } from 'react';
import logo from './logo.svg';
import './App.css';

import { useQuery, QueryClient, QueryClientProvider } from 'react-query';

const queryClient = new QueryClient();

const fetch = async function (...args) {
  const res = await fetch(...args);
  return await res.json();
};

function App() {
  // Create the count state.
  const [count, setCount] = useState(0);
  const { status, data } = useQuery('rick', () => {
    fetch('https://rickandmortyapi.com/api/character/218');
  });

  // Create the counter (+1 every second).
  useEffect(() => {
    const timer = setTimeout(() => setCount(count + 1), 1000);
    return () => clearTimeout(timer);
  }, [count, setCount]);

  if (status === "loading") return <p>Loading...</p>;
  if (status === "error") return <p>Error :(</p>;

  // Return the App component.
  return (
    <QueryClientProvider client={queryClient}>
      <div className="App">
        <header className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <p>
            Edit <code>src/App.jsx</code> and save to reload.
          </p>
          <p>
            Page has been open for <code>{count}</code> seconds.
          </p>
          <p>
            <a
              className="App-link"
              href="https://reactjs.org"
              target="_blank"
              rel="noopener noreferrer"
            >
              Learn React
            </a>
          </p>
          <p>
            {JSON.stringify(data, null, 2)}
          </p>
          <p>
            {JSON.stringify(status, null, 2)}
          </p>
        </header>
      </div>
    </QueryClientProvider>
  );
}

export default App;

5. yarn start

You should see something like:

Again, totally unsure what I'm missing, but thought it'd be useful to add this repro case here.
I'm using react-query version 3.13.10

[TkDodo]

@fev4 you are calling useQuery in App outside of the QueryClientProvider. The Provider must wrap all useQuery calls!

[fev4]

@TkDodo ouch! you are totally right! 😅 thanks for pointing it out

[brandiqa]

Quite happy this issue has been resolved in version 3.13.10. Am using Vite

[kculmback-eig]

Confirmed issue is fixed for us with Vite with v3.13.10

[TkDodo]

Aha, if contextSharing is set to true and it still doesn't work that is likely to be a bug in RQ itself. Indeed, now that I read through this thread again, @hmaurer already pointed this out:

Here's the reason why: the context sharing flag is itself passed via react context, c.f. v3.12.0...v3.12.1diff-0cee58d9679ff6f79b5250cc0611ce6eaf8bc46a77416a09384ae4670adc9872R34. And since we've two copies of react-query at runtime, we've two copies of QueryClientSharingContext. So even though contextSharing is enabled on the QueryClientProvider, the devtools are using a different copy of react-query with a different instance of QueryClientSharingContext, and so in the devtools React.useContext(QueryClientSharingContext) evaluates to false. I hope this makes sense!

While there are several things intermingled here and some of them has been fixed, I think it makes sense to reopen this issue to continue tracking that specific bug.

@Ephem As far as I can see, the original issue with the devtools has been fixed. With two versions of react-query, where both have contextSharing set to true, we should:

• get two versions of QueryClientSharingContext
• both should have the flag set to true
• so both should share the context to / from the window

I'd need to see a reproduction please that shows the issue. To avoid confusion, I would still close this issue. @michalHT feel free to open a new issue with a codesandbox reproduction.

[achan-godaddy]

was on react-query 3.24.4 and still getting this. Seems to have been caused by a strange yarn resolution on this side even though we had the resolutions set in package.json to "force" this version. In the end it was another library in the mono-repo we were using and changing from to a peerDependency from a dependency seems to have solved it. Whatever it is it seems like ensuring only one true version of react-query is being loaded. Hope that helps in case you've tried the above.

[EliseyMartynov]

Me facing this too...
"react-query": "^3.34.16"
"vite": "^2.8.4"
I don't use dev tools. Any ideas?

[mleralec]

Hey, I have the same problem with:

"react-query": "^3.34.19",
"vite": "^2.9.2",

If I remove the <ReactQueryDevtools />, it works, any ideas?

[grmlin]

Hey, I have the same problem with:

"react-query": "^3.34.19",
"vite": "^2.9.2",

If I remove the <ReactQueryDevtools />, it works, any ideas?

same thing happened here after upgrading vite to 2.9.2. But 2.9.3 was just released and seems to fix it 👍🏻

[chroth7]

Hey, I have the same problem with:

"react-query": "^3.34.19",
"vite": "^2.9.2",

If I remove the <ReactQueryDevtools />, it works, any ideas?

same thing happened here after upgrading vite to 2.9.2. But 2.9.3 was just released and seems to fix it 👍🏻

doesn't work for me right now, getting the error with vite 2.9.3 and 2.9.4. Will keep investigating

[grmlin]

doesn't work for me right now, getting the error with vite 2.9.3 and 2.9.4. Will keep investigating

yeah, while it worked for some time, it suddenly stopped again. I'm back to 2.9.1 for now :/

[coolcorexix]

I am having this error too, link to reproduce error: https://github.com/coolcorexix/saleshood-playground/tree/vite-react-query-err

My investigation is that it currently break with Vite 3.0

[JustOssa]

Hey, I have the same problem with:

"react-query": "^3.34.19",
"vite": "^2.9.2",

If I remove the <ReactQueryDevtools />, it works, any ideas?

Same with

"react-query": "^3.39.3",
"vite": "^4.3.0",

After adding ReactQueryDevtools

[TkDodo]

You probably use the wrong devtools

[JustOssa]

You probably use the wrong devtools

I did :/ thanks

[stedi4gw]

I am having this same error even without the dev tools, and I've triple checked that my "useQuery" calls are way down the tree, and the provider is the very top of the stack:

• "@tanstack/react-query": "^4.29.23"
• "vite": "^4.3.9"

I can use react-query v3.x with vite, but v4.x (@tanstack/react-query) has this problem. Back to react-query 3.x 😢