A rollback notice must say why it failed and whether retry is possible

What it is

Rollback has already spoken and content has already returned to pre-failure. If the notice is only “it’s gone”, people still do not know the next move. Reason and whether retry is possible is the minimum payload: why this write did not land (permission, quota, network, moderation), and whether tapping again now would mean anything. Showing only disappearance folds a handleable failure into a magic trick.

This leaf assumes failure was emitted as an event and the UI rolled back cleanly. It writes the two items that sentence must carry, not “whether to speak”.

Why it happens

Once failure is perceived, people attribute and choose a policy at once. Attribution wants a reason: my fault (a missing field), a temporary fault (the network), a permanent fault (muted). Policy wants “retryable”: yes, redeliver the same intent; no, change parameters or stop. Missing either scrambles the decision. No reason, only “retry”, and they will hammer the same bad parameters until quota dies. A reason without yes/no, and they will mash “no permission” or abandon a whole evening’s draft over a network blip.

“Content vanished” completes the state machine’s rollback; it does not complete the dialogue turn. The turn still owes an actionable sentence. Short, but both items present: the reason in the other party’s words (“you do not have permission to edit this channel”), the yes/no as a named next step (“kept as a draft, will send when the network returns” or “this content cannot be sent”). A foggy “something went wrong, try later” states both as unknown, which is stating nothing.

Where it stops holding

If the reason would leak a fact the current user should not know (“this user has blocked you”, which some products deliberately recode as delivery failure), copy may degrade, but retryability must stay honest: if it cannot be retried, do not offer a retry control. A security refusal (risk engine, second factor) may be vague to the user and clear to audit; on the interface at least “do not tap the same thing again now” must be clear. In a batch whose reasons differ, one umbrella reason lies; drill-down must exist. For language and access, reason and retryability cannot ride colour or icon alone: a red cross is neither.

Applying it

• Fix two slots on a rollback notice: one sentence of reason, one next action (retry / change then retry / give up). A notice with no next step fails.
• When retryable, keep the original intent (same idempotency key or same draft). Do not make people write from blank.
• When not retryable, remove the retry door, so a permanent failure is not treated as temporary.
• How to check: manufacture three rollbacks — network, permission, quota. A person who did not see the request should be able to name the reason class and correctly choose “try at once” or “do not try”. Then a path where content only vanishes and the bottom of the screen is empty — that is rollback without a turn.

Related

• Same group: I3.09.1 Rollback must restore the pre-failure UI, not leave a pending ghost · I3.09.2 Stacked optimistic steps need a defined rollback radius · I3.09.4 Don't commit later decisions to an unconfirmed optimistic result
• Nearby: I3.02 Optimistic updates · I2.08 Load failure
• Search terms: rollback copy · retryable error · failure reason