In documentation for "Invalidation from Mutations", why isn't invalidateQueries awaited?

[kkalavantavanich]

In the documentation for "Invalidation from Mutations", there is an example:

 import { useMutation, useQueryClient } from 'react-query'

 const queryClient = useQueryClient()

 // When this mutation succeeds, invalidate any queries with the `todos` or `reminders` query key
 const mutation = useMutation(addTodo, {
   onSuccess: () => {
     queryClient.invalidateQueries('todos')
     queryClient.invalidateQueries('reminders')
   },
 })

Why are the invalidateQueries methods not awaited, as in:

{
   onSuccess: async () => {
     await queryClient.invalidateQueries('todos')
     await queryClient.invalidateQueries('reminders')
   },
}

or a similar parallelized awaited promise? Is it not important that the onSuccess completes when the inner promise completes?

[meandillar]

Could be wrong but I'm under the impression invalidateQueries is synchronous

[kkalavantavanich]

The API document for invalidateQueries awaits though:

await queryClient.invalidateQueries('posts', {
   exact,
   refetchActive: true,
   refetchInactive: false
 }, { throwOnError })

https://react-query.tanstack.com/reference/QueryClient#queryclientinvalidatequeries

[HansBrende]

@kkalavantavanich @meandillar From looking through the source code, it appears there is both a synchronous and an asynchronous component of invalidateQueries. The synchronous component marks the queries as invalid, and the asynchronous component refetches all of the invalidated queries. So... if you want to wait until every invalidated query is refetched, use await. Otherwise, if you want to return immediately after the queries are marked as invalid and "fire and forget" the refetches, no need for await. At least, that is my understanding from a brief perusal of the source code.

@tannerlinsley is this understanding correct? Could be documented better if so... I spent some time trying to figure this out as IntelliJ was giving me Promise returned from invalidateQueries is ignored warnings. But if I return the promise, then it takes longer than necessary to finish.

[Note: IntelliJ's suggested fix to these warnings is to append .then(); I could be wrong, but I don't think this is necessary... but I guess I will append .then() anyway to get rid of the warnings 😅 ]

[TkDodo]

I think that sounds right. If you're not awaiting the promise, you basically have a "floating promise", and that's what IntelliJ "warns" about. You can turn that warning off though, a fire-and-forget doesn't have any real impact. There are typescript-eslint rules that forbid floating promises. To make it explicit, you can add the void operator:

onSettled: () => void queryClient.invalidateQueries(...)

I personally think that's quite explicit, but then again, there are lint rules that forbid the void operator 🤷

[HansBrende]

Perfect, thanks! That is exactly what I was looking for.

[rnz269]

You can turn that warning off though, a fire-and-forget doesn't have any real impact.

If the background refetch that occurs upon invalidation returns a rejected promise, since we're not awaiting it, wouldn't it go uncaught and thus cause an issue?

[TkDodo]

unless you pass throwOnError: true, react-query will catch errors on invalidation / refetch to avoid this:

query/packages/query-core/src/queryClient.ts

Lines 323 to 325 in c376158

	if (!options?.throwOnError) {
	promise = promise.catch(noop)
	}

the promise is mainly returned so that you can wait for it to be finished if you want to, but you don't have to.