Why does my optimistic update have a race condition even though I call cancelQueries?

[codinginflow]

I have implemented optimistic updates into my shopping cart. I noticed that when I modify different items in rapid succession, sometimes there is a glitch in the UI.

My optimistic mutation is structured as described in the documentation and I cancel the running query at the beginning of onMutate.

Why do I still seem to receive outdated values?

If I comment out invalidateQueries, it seems to work. But then I don't get the latest cart data.

export function useUpdateCartItemQuantityMutation() {
  const queryClient = useQueryClient();

  const { toast } = useToast();

  return useMutation({
    mutationFn: (variables: UpdateCartItemQuantityValues) =>
      updateCartItemQuantity(wixBrowserClient, variables),
    onMutate: async ({ productId, newQuantity }) => {
      await queryClient.cancelQueries({ queryKey });

      const previousState =
        queryClient.getQueryData<currentCart.Cart>(queryKey);

      queryClient.setQueryData<currentCart.Cart>(queryKey, (oldData) => ({
        ...oldData,
        lineItems: oldData?.lineItems?.map((lineItem) =>
          lineItem._id === productId
            ? { ...lineItem, quantity: newQuantity }
            : lineItem,
        ),
      }));

      return { previousState };
    },
    onError(error, variables, context) {
      queryClient.setQueryData(queryKey, context?.previousState);
      console.error(error);
      toast({
        variant: "destructive",
        description: "Something went wrong. Please try again.",
      });
    },
    onSettled: () => {
      queryClient.invalidateQueries({ queryKey });
    },
  });
}

[TkDodo]

I noticed that when I modify different items in rapid succession, sometimes there is a glitch in the UI.

The race condition probably comes from too many invalidations. I think this is what happens:

• you fire off the first mutation, there's nothing to cancel, and optimistically update the UI
• you fire off the second mutation, again, nothing to cancel, and optimistically update the UI
• first mutation succeeds, invalidates - the invalidate doesn't yet know about the second mutation because it might not have committed to the database yet.
• the invalidation completes and "reverts" your second optimistic update
• now second mutation finishes and invalidates again

It's a rare case where the invalidation basically "overtake" the second mutation, and it will be consistent eventually, so I don't think it's a big deal. However, one good solution I'm teaching in my course is to not invalidate after every mutation, but only after the last one. You can tag them with a mutationKey (optimistic updates left out for brevity):

  return useMutation({
    mutationKey: ['updateCartItemQuantity'],
    mutationFn: (variables: UpdateCartItemQuantityValues) =>
      updateCartItemQuantity(wixBrowserClient, variables),
    onSettled: () => {
      if (queryClient.isMutating({ mutationKey: ['updateCartItemQuantity'] }) === 1) {
        queryClient.invalidateQueries({ queryKey });
      }
    },
  });
}

Now this will only invalidate if there is only 1 mutation running (the single mutation itself) for that key, so in rapidly fired mutations, you'll only get one invalidate at the end, which is likely what you want anyways.

[codinginflow]

I think that estimation is spot on!

You say this is rare, but what makes it rare? It seems to me that every optimistic mutation that is followed by an invalidation would have this problem, no?

Thanks for your solution, this looks great.

[TkDodo]

it's rare because you need to allow a user to fire the same mutation multiple times. It can happen on a "like" button that you optimistically flip for example, and the user clicks it 5 times fast. But it cannot happen e.g. on a detail page where a submit will redirect you to the list page where you see the optimistic result of the mutation in the list.

[codinginflow]

Ah yes, that makes sense. A cart item quantity button is quite likely to be clicked multiple times in a row.

Your approach seems to mitigate the problem well enough. I think occasionally, I still saw a glitch, but much less often.