Does combining paginated infinite scroll, streaming, and optimistic updates cause potential race conditions?

[LukeCSYello]

In essence, the issue I am worried about is:

• You have data state A, representing the entire cached list
• You send request to update some item a in A (or add, or delete, but I will use update for the sake of the example)
• You store copy of A for rollback
• You optimistically update to state B
• Meanwhile, websocket updates data to state C
• If the request fails and you rollback to A, you lose state C

Or more concretely:

• I have a getMessages query that returns a list of messages. This takes a limit and page as parameters. I am modifying using merge for the getMessages endpoint in enhanceEndpoints to update the message state (similar to https://stackoverflow.com/a/74844699)
• I have an updateMessage mutation that updates a message by its id. I am using onQueryStarted to implement the optimistic update (essentially using the optimistic update recipe described in the documentation)
• I have a socket middleware that listens for e.g., message updated event, and some event handler that receives the updated message data and dispatches api.util.updateQueryData to update the message by finding its id and updating with the newly received message data

And excluding optimistic updates for a moment, would this simple scenario potentially suffer from race conditions?

• E.g., loading a new page by triggering the infinite scroll (state A, existing cache prior to any request), a new notification is received and the existing data is updated (state A -> state B, modified by notification), whether the resolved new page request will update to go from state A -> state C or state B -> state C

[markerikson]

There's definitely potential for race conditions, yes.

[LukeCSYello]

Thanks for the quick answer!

Is there any pattern or approach you would recommend for preventing the race condition? Is there any approach built into RTK query to handle locking?

[markerikson]

Not in that sense, no.

RTKQ tracks the saved status of any given cache entry in the Redux state, ie, {status: "pending"}. Conceptually it's tracking the status of a given promise (pending | fulfilled | rejected).

If you're doing your own async work outside of RTKQ's internals, that's nothing we know about or can track ourselves.

[LukeCSYello]

Thanks, that makes sense. I think I'll have to rethink my approach to optimistic updates in that case.

Would the more simple scenario I described at the bottom of my initial post pose the same potential for race conditions?

E.g., loading a new page by triggering the infinite scroll (state A, existing cache prior to any request), a new notification is received and the existing data is updated (state A -> state B, modified by notification), whether the resolved new page request will update to go from state A -> state C or state B -> state C

So by the time the promise for fetching the new page of data (triggered by infinite scroll or whatever) resolves, does it modify some snapshot of the state taken as the request starts, or does it modify whatever would happen to be the latest data in the cache (if it is updated in the meantime by some other async operation, e.g., a web socket notification)?

[markerikson]

does it modify some snapshot of the state taken as the request starts

No. This is Redux, so it's still (state, action) => newState. The reducer works with whatever the current value of the cache entry is in the state at the time the action is dispatched.

[LukeCSYello]

Thanks for clarifying!