Interrupted work has to come back
Aliases: crash recovery · offline recovery · uncommitted work
What it is
A killed process, a crashed tab, a network drop before submit: what someone believes they are still editing lives only in memory that is about to vanish. Recovering uncommitted work means those inputs, not yet official records, can return after the interruption. This entry is only about “it has to come back.” It is not about whether a person must agree before it is applied, and not about how to speak when it is truly gone. It is also not the ongoing autosave cadence of a form as such.
Why it happens
Uncommitted work is bound to a volatile layer: the field, a local draft, a request that never got a reply. The interruption cuts the process or the channel, not the intention. After restart, people match “where was I” against the world; if the world is empty, the loss happened invisibly at the interruption and is noticed minutes later. Recovery moves the volatile layer to still-living storage before the cut: local persistence, a draft that reached the server, a replayable request. Grain has to be small enough that a keystroke or a pause has a chance to be kept, or “recovery” only covers a version from minutes ago and the last words still die.
Studying it
During an editing task, inject kill-process, close-tab, and drop-network, with and without persistence before the cut.
Independent variables: persistence interval, storage (memory only / local / already on the server), interruption type. Dependent variables: difference between recovered content and content just before the cut, time to notice loss, whether already-written passages are retyped.
Lab interruptions are advertised, so people save early. A harder probe kills the process while they think the task is still running. Do not only measure whether a recovery prompt appears; diff the text.
Where it stops holding
Sensitive fields (passwords, one-time codes, payment secrets) must not enter the recoverable layer; emptiness after an interruption is intentional. Read-only browsing has no uncommitted work to recover. When several people are editing the same passage, a local recovery may conflict with a version already submitted—that is the next step’s confirmation problem, but “there is something to recover” still has to hold first. Recovery that lives only in memory is nothing after a killed process.
Applying it
- On long input, write to local storage or a draft API after a pause, with an interval so short that one interruption loses the last few words, not a whole paragraph.
- Record an idempotency key and payload for in-flight submits, so reconnect can query or replay safely.
- Exclude password-class fields from recoverable storage.
- Verify by typing a passage that cannot be copied from elsewhere, force-killing the app, reopening, and diffing. If the gap is larger than the last obvious pause, the interval is too long.