duplicated invalidate sent in very close time, how to maintain the order

[mengxi-ream]

I have a sheet app optimistic updating value in "cell" by the following function, it will:

1. optimistic update the value of the cell at position of function table.getCells({ tableId })
2. After successful mutation, it will invalidate table.getCells({ tableId })

import { api } from "@/trpc/react";

export function useUpdateCell() {
  const utils = api.useUtils();

  const updateCell = api.table.updateCell.useMutation({
    async onMutate({ tableId, position, value }) {
      await utils.table.getCells.cancel({ tableId });
      const prevCells = utils.table.getCells.getData({ tableId });
      const [col, row] = position;
      const prevCell = prevCells?.[row]?.[col];
      if (!prevCell) {
        throw new Error("Cell not found");
      }

      utils.table.getCells.setData({ tableId }, (prev) => {
        const newCells = prev ?? [];
        if (!newCells[row]) {
          throw new Error("Row not found");
        }
        newCells[row][col] = { ...prevCell, value };
        return newCells;
      });

      return { prevCells };
    },
    onError(_error, input, ctx) {
      utils.table.getCells.setData({ tableId: input.tableId }, ctx?.prevCells);
    },
    onSettled(_data, _error, input) {
      void utils.table.getCells.invalidate({ tableId: input.tableId });
    },
  });

  return updateCell;
}

Now, let's say the network is pretty slow and we have 4 mutation requests (mutate the cell at position: col = 1, row = 0) in order:

1. mutate the cell value to 1 (mutation #91)
2. mutate the cell value to 12 (mutation #92)
3. to 123 (mutation #93)
4. to 1234 (mutation #94)

I EXPECT to always see 1234 at the cell finally. But I saw 12 at the end in very slow network environment. Here is the log:

I believe the reason that seeing 12 not 1234 at the end is somehow query #73 with the cell value 12 is the last response among all queries?

Could anyone tell me how to solve this problem (always return the last mutated value like 1234)

Btw, the last value in database is 12 not 1234

[TkDodo]

A good idea is to only invalidate in onSettled if there is no other mutation running that concerns you, for example:

const useMyMutation = (id) => {
  return useMutation({
    mutationKey: ['updateCell', id],
    mutationFn: () => ...,
    onSettled: () => {
      if (queryClient.isMutation({ mutationKey: ['updateCell'] }) === 1) {
        return queryClient.invalidateQueries(...)
      }
    }
  })
}

The check for 1 is necessary because the mutation itself is still in mutating state when the callback is executed.

This way, when you have concurrent mutations, you will ensure that only one invalidation runs at the very end of the chain, and you avoid those in-between invalidations that you likely don’t want. And if another mutation starts after the last mutation triggered an invalidation, the cancelation in onMutate will make sure that this result is discarded.

Note that I’m also returning the result of the query invalidation. This makes sure that the mutation stays in pending state while the invalidation is still going on.

[mengxi-ream]

Thank you for the response. I believe this has resolved the issue with the data from the query flickering. However, it seems that we still need a server-side fix to prevent the mutation to 12 from running if we have already executed a mutation to 1234.

The problem I mentioned in this post actually caused by the request to mutate to 1234 arrive earlier than mutation to 12, so server will update to

1. to 1234
2. then to 12
   So finally it render's 12 because in the database it's 12.

Anyone has the comprehensive solution for this?