Your suspicion is right, and there are two separate bugs producing the two symptoms.
The flicker is an in-flight refetch landing on top of your optimistic write. You write the optimistic value; a query that was already running finishes and writes the server's old value; your error handler then writes your snapshot. Three writes, and the middle one is not yours.
The fix is to cancel outgoing queries for that key before you write optimistically. Every good implementation of this starts with that step and it is the one people skip because the happy path works without it.
The wrong final value is your rollback writing a stale snapshot. If you captured the old value when the mutation was defined rather than immediately before the write, or if two mutations overlap, the value you restore is not the value that was there.
So the correct sequence, in order, and the order is the whole answer:
- Cancel in-flight queries for the affected key
- Read the current cached value and keep it as the rollback snapshot
- Write the optimistic value
- On error, write the snapshot back
- On settled — success or error — invalidate the key so the server has the last word
Step 5 is what fixes the state that persists until you navigate away. Without it, a failed rollback is never corrected by anything.