Rule

Every optimistic UI update must have a defined rollback path on failure.

Why

Optimistic updates that do not roll back leave the UI in an inconsistent state that can corrupt user data.

Must

• Store the pre-update state before applying optimistic changes.
• Revert to previous state on server error.
• Notify the user when a rollback occurs.
• Only apply optimistic updates for operations that are highly likely to succeed.

Should

• Offer a retry action after a failed optimistic write.
• Show a subtle pending indicator rather than immediate "success" for critical writes.

Anti-patterns

• Applying optimistic updates to financial operations.
• No rollback on network failure.
• Showing a persistent success toast before the server confirms.

Test Cases

• Simulated 500 triggers rollback and user-facing error.
• Offline state prevents optimistic update from being applied.

Telemetry

• optimistic_update_applied
• optimistic_rollback_triggered
• optimistic_retry_clicked