Retry

Problem Context

• The product can distinguish transient failures from validation, permission, policy, irreversible, or final-state failures.
• The same request, object, inputs, filters, or upload can be preserved and attempted again.
• Repeated attempts can create duplicate records, charges, emails, exports, queue items, or service load unless guarded.
• Users need to know whether a retry is pending, waiting, succeeded, failed again, exhausted, or unavailable.

Selection Rules

• Choose retry when a specific failed operation can plausibly succeed if attempted again under the same scope.
• Name the retried operation and object so users understand what will repeat before they activate it.
• Keep user-entered data, request parameters, selected files, filters, and destination details intact across failed attempts.
• Disable or debounce Retry while an attempt is in flight, and never leave an unsafe duplicate submit path beside it.
• Use idempotency keys, request references, upload IDs, message IDs, or server deduplication for side-effecting operations.
• Use capped backoff, jitter, attempt limits, or server-provided retry timing rather than immediate repeated loops.
• Stop offering retry for validation errors, missing required data, denied permission, final deletion, unsupported state, or policy decisions.
• After repeated failure, switch to fallback, cached data, background completion, export local copy, contact support, or return-later guidance.
• Use error state for the broader persistent failure surface and Retry as one action inside that surface.
• Use offline state when the primary issue is connection mode and local or queued work behavior rather than one failed operation.

Required States

• Retryable failed state with affected operation, object, and preserved request context.
• Retry-ready state with a specific action label and safe scope.
• Retry pending state that disables duplicate attempts and confirms the same request is being sent.
• Retry succeeded state that returns users to recovered content, completed action, or download access.
• Retry failed again state with updated attempt count and cause.
• Cooldown or backoff state with next allowed attempt time or wait reason.
• Retry exhausted state with fallback, background, support, or return-later path.
• Non-retryable state that routes to correction, access request, policy explanation, or support instead of Retry.
• Duplicate-guarded side-effect state with idempotency, request reference, or deduplication visible enough for support.

Interaction Contract

• Retry repeats the same failed operation against the same request scope unless users explicitly edit that scope first.
• Activating Retry moves the control into a pending state and prevents a second activation until the attempt resolves or is cancelled.
• The interface reports success, still failed, cooldown, exhausted, or non-retryable outcome after each attempt.
• Retry does not clear forms, filters, selected files, drafts, or destination context unless the user deliberately resets them.
• If retry would create external side effects, the client and server share an idempotency or deduplication contract.
• Automatic retries respect attempt caps and backoff; manual retry does not bypass safety limits that protect the user or service.
• When the failure cause changes to validation, permission, policy, or final state, the UI replaces Retry with the action users can actually take.

Implementation Checklist

• Classify failures into retryable transient, retryable after cooldown, user-correctable, permission-related, final, and unknown categories.
• Persist the original request payload or safe request reference so Retry does not broaden scope or lose user-entered data.
• Add idempotency keys or server-side deduplication for create, update, payment, send, invite, export, import, upload, and queue actions.
• Track attempt count, last attempt time, next allowed attempt, current in-flight request, and terminal exhausted state.
• Show operation-specific copy such as Retry export, Retry upload, or Retry connection check instead of an unexplained Try again.
• Guard against double click, keyboard repeat, back navigation, page refresh, and multi-tab duplicate attempts.
• Apply capped backoff and jitter for automatic or repeated attempts, and respect Retry-After or equivalent server timing when available.
• Announce retry pending, success, repeated failure, cooldown, exhausted, and non-retryable changes in a status region.
• Test success after retry, repeated failure, timeout, cancellation, offline transition, duplicate activation, stale request reference, and support escalation.

Common Generated-UI Mistakes

• Offering Retry for every error regardless of whether the user or system state can change.
• Retrying immediately in a tight loop during service overload.
• Leaving both Retry and the original submit button enabled for the same side-effecting operation.
• Changing filters, selected files, amount, recipient, or destination between attempts without telling users.
• Hiding attempt count and cooldown, making users think the control is broken.
• Using retry to mask validation, permission, or policy errors that need correction or access.

Critique Questions

• What exact operation will run again, and can users see that scope before activating Retry?
• Why is this failure retryable rather than user-correctable, permission-related, final, or a broader outage?
• What prevents duplicate charges, records, messages, uploads, or exports if the first attempt actually reached the server?
• What is the attempt cap, backoff rule, and next path after repeated failure?
• Does the retry preserve forms, filters, files, scroll context, and request identity?
• Can keyboard and assistive technology users tell when retry is pending, cooled down, exhausted, or unavailable?