React.StrictMode and useQuery causing double active queries

[Vuliniar]

Hello,

This issue already exist in opened issues, but I found more problems it causes. In React.Strict mode active queries are getting doubled and leading to very annoying bugs - sometimes even hard to spot and debug.

Here is the example in our codebase:

1. Component uses useQuery with variable (which is dynamic and depends on state)
2. In active queries, because of React.StrictMode, we get duplicated query as active (?)
3. after the variable has been changed useQuery runs again (which is fine and expected behavior)
4. I'd asume we should have only one active query, but because of point 2 (above) we still have 2 active queries but this time one active query with initial variable (from point 1 above) and second query with changed variable

Outcome: So in active queries we end up having queries which are not indeed active (duplicates)

What it causes? If we by any chance do refetchQueries, it will refetch even the query we don't need (but because it is in active queries apollo refetches it). It leads to some serious bugs - you're requesting one type of data (based on variable) and getting something totally different (so cached objects also get affected, keyargs, etc..).

If we remove React.Strict mode (which I'd argue is bad idea) everything seems to work.

Thank you!

[kainosnoema]

We just ran into this as well. Not just duplicate, but any permutation previously mounted queries apparently stay active and are triggered by refetchQueries (sometimes dozens of the same single component query). We thought it was a bug in our code and spent hours debugging before stumbling on this and discovering that removing StrictMode immediately solved it.

Is there some sort of cleanup that Apollo should be doing to be compatible with StrictMode / React 18?

[majjhima]

I am also experiencing this problem. For me the issue causes a problem with the first render of useQuery having a pollInterval set with the initial variables and then after changing the variables such that the pollInterval gets set to 0, I get the new data back, but it shortly gets replaced by the original polling query which is definitely the wrong data.

[phryneas]

Hey there,
generally, yes, strict mode will lead to request being made, teared down, and made again. That is what StrictMode is there for - to test in development that requests are teared down correctly.

We do delay the "tear down" for a short moment, so the next request can latch onto the existing network request and doesn't trigger another network request, and we generally deduplicate network requests.

Unfortunately, all the descriptions you are giving us here are very vague and will not help us to reproduce the issue. I also believe that the three of you (@Vuliniar , @kainosnoema , @majjhima ) are experiencing three independent problems here.

Could you please provide us with minimal reproductions of your issues so we can take a look at them?

[damikun]

Equal if query with suspense... Only appear in StrictMode not in prod...

[jerelmiller]

Hey @damikun 👋

Would you be able to provide a reproduction and a more detailed description of what you're seeing? For useSuspenseQuery, we explicitly test that only 1 request is made while using strict mode with all fetch policies. Perhaps you're seeing different, but a reproduction or failing test with a more detailed description would help tremendously. Thanks!

[levrik]

@jerelmiller @phryneas

I'm seeing the same issue. I wouldn't say I'm doing anything special besides quite standard Apollo Client usage.
This super simple example reproduces the issue: https://codesandbox.io/p/devbox/recursing-surf-tmwx9d

Just look at the logs in the Chrome dev tools. We only have a single query in the whole application, still looking into queryManager.queries logs 2 entries in total.

[phryneas]

@levrik did you mean to share a link to a modified reproduction? That is the unmodified error reproduction template.

And executing __APOLLO_CLIENT__.queryManager.queries in the console there gives me just one query.

[levrik]

@phryneas Already updated the link. CodeSandbox's share feature gave me the link of the template for some reason until I did a full reload of the page.

[phryneas]

Ah, gotcha.

Yes, there are two queries there, but only one of them is an "active" query, which is what this issue if about.

You can see that by calling client.getObservableQueries().

[levrik]

@phryneas That's true but for example as mentioned above refetchQueries with a DocumentNode doesn't take this into account. As explained over at #11894 (comment) by @jerelmiller, Apollo Client seems to rely on inactive queries to be removed from queryManager.queries for refetchQueries.

Since queryManager.getObservableQueries() gets passed an explicit list by queryManager.refetchQueries(), it simply returns all observables for given queries regardless of active/inactive state.

So either refetchQueries needs to do some additional filtering or queries must be correctly removed from queryManager.queries.

[phryneas]

Yeah, this is definitely be something to look into, my main point right now is that it's a different issue from this issue, because in the past, actually, both of these queries were "active". Could you please open a new issue so we can track this separately?

(This is actually a good reminder to close this issue, since it should have been solved quite a while ago)

[levrik]

@phryneas I see. Wasn't super clear to me from the issue description that it was really above "active" queries or just queries that seem to be active. Let me file a separate issue.

[phryneas]

Meanwhile I'll close this issue. See you in the new one!

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.

[levrik]

@phryneas Opened #12228