The principle underneath the sequence above, which makes it easy to remember: the optimistic value is a guess with a deadline, and the server response ends it either way.
A lot of the mess comes from treating the mutation's own response as the new truth and writing it into the cache instead of refetching. That works until the server does something you did not model — a computed field, a timestamp, a side effect on a related record — and now your cache is a plausible fiction. Invalidating and letting the query refetch is slightly slower and always correct.
Two places this shows up:
Lists. Optimistically adding a row means inventing an id. When the server responds with the real one, you either reconcile carefully or you refetch. Refetch, unless you have measured that you cannot afford to.
Anything with ordering or aggregation. A toggle that changes a count somewhere else is exactly where hand-maintained cache updates go wrong, because you have to remember every derived thing.
The rule I use: optimistically update for feel, invalidate for truth. The optimistic write buys you the instant response; the invalidation makes sure that after a second, what is on screen is what is in the database. If those two ever disagree permanently, you have a bug you cannot see.