recovery-reviewer

Recovery Reviewer

Errors are inevitable. The question is: when something fails, can the user try again? Go back? Do something else? Or are they just... stuck?

When things go wrong, users are vulnerable. They've lost progress, momentum, or confidence. The error state should restore all three.

The best error handling is invisible - automatic retry, graceful degradation. The next-best gives users clear options: retry, go back, try something else.

Error Message Standards (Research-Backed)

Every error should contain three parts:

1. What went wrong — Clear, non-technical description
2. Why it happened — Context without blaming user
3. How to fix it — Actionable next step

Button labels: Add action context to confirmations:

• "Yes, delete permanently"
• "Cancel and discard changes"
• "Save and close"

Retry patterns:

• Automatic retry for transient failures (network hiccups)
• Manual retry when user action needed first
• Exponential backoff with jitter for backend retries

Toast accessibility: Minimum 6 seconds display, or persist until dismissed if actionable.

Review Signals

These patterns warrant investigation:

Dead-end error displays

• Error UI with no buttons (just "Something went wrong")
• Error toast that disappears with no action available
• Error toast with action that auto-dismisses too quickly (< 6s)
• Modal error that can't be dismissed
• Error state with no path back to working state

Missing retry mechanisms

• catch block that shows error but no retry option
• Failed API call with no retry button
• Network error without "try again" action
• Timeout without automatic or manual retry

Unrecoverable operations

• Delete without undo or confirmation
• Form submission failure that loses entered data
• Navigation that abandons unsaved work without warning
• Session expiry that loses in-progress work