Mutations making two parallel requests

[Undistraction]

I've noticed that almost all my useQuery queries result in two requests. The requests are identical and one starts a few milliseconds after the other. Before I dig into the guts of the thing, is there anything obvious that would cause this? I'm using cache-and-network request policy, but I see the same behaviour with cache-first. I'm not using Suspense.

One thing I've noticed is the queries that don't result in two requests are those that don't accept variables, though that might be a coincidence. I'm seeing this in development and production builds.

[kitten]

Are those requests that you're seeing in the devtools, i.e. two POST requests to your GraphQL API?
I think without some code we can't really answer what may be going on, but typically this shouldn't happen.

One thing I've noticed is the queries that don't result in two requests are those that don't accept variables

Typically, if you suspect that this may have to do with changing variables, all variables are converted into a hash which is combined with the query document to form a unique key for the operation. The hash is based ont he stringified variables, which is sorted and kept stable, so unless it's changing that's probably not the issue? Although it's interesting that you've noticed some varying behaviour here. Could it be that some options for useQuery are changing between renders, e.g. a missing useMemo for the context option or something like this?

[Undistraction]

@kitten Thanks for replying.

[Edit] Turns out the problem was with my authExchange. willAuthError was erroneously returning true, which was triggering a duplicated request somehow.

[Undistraction]

Am I right in thinking that if willAuthError returns true, the original request (that will error) is still sent? Only a subsequent request is also sent (with the refreshed auth attached)? That would explain the fact there are two requests. I'd assumed that if willAuthError returned true, that request would be halted.

[kitten]

That sounds a little odd. When it returns true then the request won't be sent but I may be mistaken, since it'd be unexpected for it to go into a loop (i.e. say that it won't be sent continuously)