Optimistic UI can desynchronize unlock from result feedback

What it is

An optimistic update writes success before the server confirms: the like lights at once, the comment appears at once. The button is often unlocked immediately so the person can go to the next item. A later rejection rolls the UI back, while the button already looks idle. Unlock timing and result-feedback timing have drifted: the person thinks the event ended, but it is still a bet on the network. Another tap stacks a second optimistic record, and rollback gets messier.

Why it happens

The optimistic path collapses “input received” and “result produced” into one frame. If the button unlocks because “the UI already changed,” the lock tracks perceived end, not transaction end. When the true result arrives late and is failure, rollback happens after the person has left this item, or even taken a next step on the back of success (closed the dialog, advanced a feed). If the button stays locked until server confirm, the lightness of optimistic UI dies and people mash—and in an optimistic model each mash creates a local record. The sync problem is not whether to be optimistic. It is which moment the lock should track: a very short lock at send still stops a double fire in one frame; a pending mark during unconfirmed work stops “idle means done,” rather than dressing the button as fully free.

Studying it

Build an optimistic like/comment, vary confirm delay and failure rate. Log unlock time, when success look appears, when rollback happens, and whether people tap again in between.

Independent variables: unlock aligned to UI change versus server confirm, whether failure rolls back, whether a pending mark is visible. Dependent variables: duplicate optimistic records, confusion reports after rollback, next steps taken on unconfirmed success (closing the page).

Short lab delays hide the desync. Stretch confirm to several seconds and allow people to leave the item.

Where it stops holding

Local-only actions with no server have none of this desync. Strongly consistent payments should not unlock optimistically. In collaborative editing, pending is normal; the button may stay available and pending is a sync mark in the document, not a button lock. Autosave is a pending document more than a loading button.

Applying it

• On optimistic success, the loading look may end, but leave a pending mark (muted color, a dot, not yet synced). Do not dress final success.
• Still take a very short synchronous lock at send so one frame cannot double-fire. A tap during pending should be explicit: “another one” versus “still waiting on the first.”
• On rollback, the button must be hittable again, and copy should say the last one did not send.
• Verify by confirming failure after five seconds. Watch whether people leave in that window thinking it succeeded, and whether the error is still findable on that button at rollback. Idle-as-done plus a vanishing rollback is desynchronized timing.

Related

• Within the group: E1.17.1 Click-submit and Enter-submit must share one lock · E1.17.2 Touch delay can let two quick taps both count as valid · E1.17.3 After a network failure the button must unlock into a clear error
• Adjacent: D1.11 Distinguishing input receipt from result production · I3 State management · E1.09 Loading buttons
• Search terms: optimistic UI · rollback · in-flight