A failed optimistic update must announce the rollback
Aliases: silent revert · rollback notice · optimistic failure
What it is
The server rejects an optimistic write and the interface takes back the success it just painted — that is a rollback. Explicit disclosure means the take-back must also let the person know “that one did not write”, rather than the pixels shrinking as if nothing had occurred. A silent rollback is a second lie: the first claimed success, the second claims that nothing happened.
The requirement is that failure is emitted as an event. What the copy names as a reason, whether retry is offered, whether the surface is wiped clean of transitional traces — those are rollback-mechanism details, not this test. The test here is one sentence: the person must be able to answer “did that last tap actually land”.
Why it happens
Inside the optimistic window the screen is already treated as true. Closing the window has two shapes. One emits an event: “it did not send”. The event rewrites the model from “done” to “not done”, and later decisions can halt. The other emits no event and only rewinds pixels. A rewind is easy to miss under change blindness or when the eyes are elsewhere; even if someone sees a lit heart go dark, there is no cause for the darkening. They recode it as their own miss-tap and tap again, or as the interface twitching.
Worse is attribution inversion. After a silent rollback a comment is gone from the list; the person checks whether they deleted it, whether a refresh dropped it. Error is coded onto the user side. The server’s refusal (permission, quota, moderation) never enters awareness. The next identical action fails again, because the real obstacle was never put into the model.
Where it stops holding
Tiny, reversible, consequence-free microfeedback (a ripple on a wrong key, snap-back from an illegal drop target) already announces by the snap-back itself; no banner is owed. But once an optimistic result has been taken as input to the next step — “added to cart” then checkout, “sent” then leaving the thread — the rollback has to speak. If failure happens after the user has left this screen, the notice must chase a channel they are still in (a notification, a bar on return), not flash once at the original locus. In a batch of ten optimistic writes where one fails, shrinking only the failed row without saying so lets people believe all ten landed.
Applying it
- Every optimistic failure emits a perceivable event: an in-place error, a failed state on the row, or a note still readable on return. Never rewind pixels alone.
- The event must at least complete this blank: “X just now did not succeed”.
- If the user has left the original screen, send the same sentence to a channel they still look at. Do not wait for them to wander back.
- How to check: drop the network or fail the endpoint, then like, comment, or change a setting optimistically. Record the three seconds of rollback. If the picture returns to pre-failure and there is no evidence of “did not succeed”, it fails. Show the replay to someone who was not staring at the control and ask “did that land” — no answer means a silent rollback.