Autosave, Draft Recovery, and Conflicts

Working case

A reviewer changes the diagnosis of case 47, then loses connection before autosave returns. The browser stores a local draft; the header says 'Saved on this device', not 'Saved to server'. Meanwhile a colleague edits the same case from another browser and advances it to version 8. On reconnect, the first reviewer sees a conflict and chooses which text to keep. The interface preserves both values until a decision is made. A second tab with an older draft must not replace the newer confirmed version merely because its local timestamp is later.

Implementation boundary

function draftStatus(localDraft, serverVersion) {
  if (!localDraft) return "server-only";
  return localDraft.baseVersion === serverVersion ? "recoverable" : "needs-review";
}
console.log(draftStatus({ baseVersion: 7, text: "Inspect valve" }, 8));
// Output: needs-review

Store only the fields necessary for recovery, scoped by account and case ID. Keep sensitive values out of local persistence when policy requires it, and clear drafts on sign-out or record deletion. Attach a base version to each draft; a timestamp alone cannot prove which record state it descends from. Use a conditional server write and an idempotency key for retries. If offline work is supported, queue writes with order and a visible pending count, then reconcile rather than replaying blindly. The status language must reflect the last confirmed boundary.

Cost and boundaries

Writing a draft of k bytes is O(k) serialization and storage, repeated after edits; a short debounce reduces write frequency at the cost of a small unsaved window. Browser storage is finite, shared with other origin data, and may be cleared, so it is recovery help rather than a durability guarantee. Each version conflict needs human or domain-specific merge logic. The extra state and UI are justified for long forms, but a tiny low-risk form may need only explicit Save and a leave warning.

Failure trace

An autosave request times out, but the UI immediately changes its label to 'All changes saved'. The reviewer closes the tab and later finds the server's old text. Another failure is restoring a local draft solely by its local timestamp, overwriting a colleague's newer version. Keep pending and confirmed states distinct, retain the local copy until a confirmed response, and compare the draft's base version with the server version on reopen. If the server outcome is uncertain, query its current state before retrying.

Verification

• A local-only draft is never described as a server save.
• Recovery detects a changed server version before applying edits.
• Account switch clears or isolates private local drafts.

Practice drill

Edit a 120-character diagnosis, interrupt the network after the request leaves, and close the tab. Reopen and identify exactly what is local and what the server accepted. Make a second browser update the record to version 8 before reconnect. Verify the recovery UI displays both versions and requires a choice. Sign out and confirm the draft cannot appear under account 62. Fill browser storage near quota and ensure a failed local write does not create a false 'saved' label.

Decision note

Name each persistence boundary in the UI and use server version checks before replaying a recovered draft.

Common Mistakes

• Using a timestamp as a substitute for the server base version.
• Clearing a local draft before the server confirms the write.
• Ignoring quota and sign-out behavior for browser storage.

Connected lessons

Forms and Data Entry Workflows; Native Form Submission and Progressive Enhancement; Asynchronous Field Validation Races; Multipart Upload Progress and Retry Boundaries; IndexedDB for Local Drafts; Conditional Writes and Lost-Update Prevention; Form Errors and Recovery Paths.

Apply and check

Build Project: recoverable case intake form and review Web Development: rendering and forms decisions quiz.

Further connections

Undo History, Autosave, and Revision Conflicts.

Further connections

React Component Identity and Keyed Draft Lifetime.

Further connections

Vue Props, Emits, and Keyed Editor Ownership.