useMutation without parallelism

[jGleitz]

TLDR: introduce an option parallel: boolean (or similar) to ensure that a mutation with the same key only has at most one executing instance at any time.

I’m using useMutation to send PATCH requests to my backend. PATCH requests must not overtake each other. That is: if request A was sent before request B, it must reach the server before request B does. Otherwise, the result is semantically wrong.

The easiest way to ensure this behaviour is to hold back sending B until A has finished. So far I have been doing this myself, with a helper that chains together the promises of mutations with the same key (see asyncInOrder below). This approach has the major drawback that effects of previous mutations are not yet visible when the next mutation starts.

In my specific use case, I want to piggyback the patches from previously failed mutations on new mutations, to effectively re-try them when a new mutation is issued. With my current approach, I get this behaviour:

• mutation A is issued
• mutation B is issued before A has finished its task gets queued by asyncInOrder
• mutation A fails
• the task for mutation B starts. When it queries queryClient.getMutationCache().findAll() to find previously failed mutations, mutation A is not yet included in the result.
• hence, mutation B runs without re-trying A.

Hence, from my point of view, the major benefit of this library offering the queuing functionality would be that the library can ensure that the effects of previous mutations are visible to the next mutation.

Here is a code sandbox that demonstrates how previous failures are not visible to the next query with my approach:

asyncInOrder

let promiseId = 0
const outstandingPromises = new Map<string, { id: number, promise: Promise<unknown> }>()

export default function asyncInOrder<T>(key: readonly (string | number | undefined)[],	task: () => Promise<T>): Promise<T> {
	const stringKey = key.join("/")
	const id = promiseId++
	const existingEntry = outstandingPromises.get(stringKey)
	const existingPromise = existingEntry?.promise ?? Promise.resolve()
	const newPromise = existingPromise
		.then(task, task)
		.finally(() => {
			if (outstandingPromises.get(stringKey)?.id === id) {
				outstandingPromises.delete(stringKey)
			}
		})
	outstandingPromises.set(stringKey, { id, promise: newPromise })
	return newPromise
}

[TkDodo]

Not really sure yet why, but it seems that the mutations are all there, in the correct state. queryClient.getMutationCache().findAll() returns all mutations, in their correct states. It seems that filtering with queryClient.getMutationCache().findAll({ status: 'error' }) is what always returns an empty array. Need to look into this

[TkDodo]

ah okay this was a red herring; when logging, the mutations showed the correct state in the console, but when debugging it, the mutations were still in pending state. I think the problem is that asyncInOrder doesn't queue the mutations up long enough. I currently don't really see how though, because after the mutation promise resolves, we should have the latest values in the cache already.

So long story short: I don't think I want to add something built-in for this, but I definitely want this to be build-able in user-land

[jGleitz]

but I definitely want this to be build-able in user-land

I agree that this would be preferable. My assumption is that it's not possible, since the promise running after the mutationFn's promise will always race against the processing done by the library.

But I'm happy to be proven wrong.

[TkDodo]

since the promise running after the mutationFn's promise will always race against the processing done by the library.

I'm not sure I fully understand how the asyncInOrder function works, or why it would "race" against the promise from the lib?

[jGleitz]

The core of the issue is that my asyncInOrder – or any other solution that is plugged into queryFn – is bound to run its next inner Promise as soon as the current has finished. So at the time the next inner is started, the processing by TanStack query will just have been queued.

If something like a parallel option is not in line with the vision for this lib, maybe something like a processed promise would work? This would be a Promise<void> available on every mutation, that will be triggered once the mutation has been completely processed (including the onSuccess and onSettled callbacks).

With this, we could implement a function that makes the inner of a queryFn wait for when the previous mutation has been processed.

[TkDodo]

TLDR: introduce an option parallel: boolean (or similar) to ensure that a mutation with the same key only has at most one executing instance at any time.

I think we have this now with mutation scopes: https://tanstack.com/query/latest/docs/framework/react/guides/mutations#mutation-scopes