Autosave recovery

Problem Context

• The product already uses autosave or local draft persistence for meaningful form, editor, upload, or configuration work.
• The latest value may differ from the last server-saved value because of network failure, session expiry, offline mode, validation rejection, conflict, duplicate tab editing, or app reload.
• Users need to know whether the newest work is on the server, only on this device, failed, stale, conflicted, or gone.
• Continuing, submitting, publishing, or leaving could discard a local copy or commit an older server value.

Selection Rules

• Choose autosave recovery when a background save did not complete or cannot prove that the latest value is safe.
• Use autosave form for the ordinary save model before failure; autosave recovery begins when the model needs repair or preservation.
• Use draft state when users are managing a durable unpublished object across lists, publish boundaries, or shared draft ownership.
• Use retry for a simple failed operation only when no local unsaved value, timestamp ambiguity, or version choice must be preserved.
• Escalate to conflict state or conflict resolution when local and server versions both changed and users need to compare or merge them.
• Escalate to session timeout warning or reauthentication when recovery depends on restoring an authenticated session.
• Show the last saved timestamp, failed attempt time, affected section, and storage location such as server, this device, or browser storage.
• Keep the local value editable or copyable while recovery actions run; do not clear it before a successful server save or explicit discard.
• Disable or explain Submit, Publish, Continue, and navigation while failed or uncertain autosave would make the next step unsafe.
• After successful recovery, clear stale failed-save warnings and update the visible saved state to the recovered version.

Required States

• Clean saved state with current server timestamp.
• Dirty or pending local state waiting for autosave.
• Failed autosave state with affected field or section named.
• Local-only saved-on-this-device state.
• Retrying same value state with duplicate submission blocked.
• Recovered saved state with updated timestamp.
• Restore last server-saved version state.
• Recovered local copy after reload or return state.
• Version conflict or compare-needed state.
• Expired session or reauthentication-needed recovery state.

Interaction Contract

• The recovery surface appears close to the affected form, section, editor, or submit action and remains until the risk is resolved.
• Retry save sends the latest local value with the same field or section identity and prevents duplicate retry requests.
• Copy answer or Download copy lets users preserve local work even if the server remains unavailable.
• Restore last saved names the timestamp and consequence before replacing a newer local value.
• Compare versions shows local and server evidence when overwrite risk exists.
• Submit, Publish, or Continue is blocked or intercepted while latest required work is failed, local-only, conflicted, or unverified.
• Recovery success updates the timestamp and returns focus or status to the affected task without forcing users to retype.

Implementation Checklist

• Track server-saved value, local value, local storage key, field or section owner, save request ID, saved timestamp, failed timestamp, and retry state separately.
• Persist local copies through reload, app restart, backgrounding, and reauthentication when policy allows.
• Keep failed-save messages persistent and attached to the field, section, or submit area until recovery completes.
• Make retry idempotent and scoped to the same local value; disable duplicate Submit and Retry while saving.
• Expose safe manual preservation such as Copy answer, Download draft, or Save local copy when server recovery may fail.
• Handle validation rejection, offline mode, session expiry, duplicate tabs, stale server versions, and storage quota failures as separate recovery states.
• Log recovery outcomes for diagnostics without recording sensitive field values.
• Test slow network, failed request, offline return, reload restore, session expiry, two tabs, conflict, copy fallback, keyboard access, and screen reader status updates.

Common Generated-UI Mistakes

• Leaving a green Saved label visible after a failed or stale autosave.
• Showing only a disappearing toast for work that may be lost.
• Retrying a save after clearing the local value.
• Letting users submit an older server version while the newest local answer failed.
• Overwriting server changes from another tab or collaborator without comparison.
• Treating local browser storage as server-saved progress.
• Forcing reload or sign-in again without preserving a return target and local copy.

Critique Questions

• What exact field, section, upload, or object is not safely saved?
• Where is the newest value now: server, this device, memory, browser storage, another tab, or nowhere?
• What timestamp or version proves the visible Saved message refers to the latest edit?
• Can users retry, copy, restore, compare, or reauthenticate without losing the local value?
• What actions must be blocked until recovery succeeds?
• How does the UI resolve a conflict between local and server-saved values?