After cancel, say what happens to work already done
Aliases: partial result after cancel · leftover disposition · half-finished abort
What it is
A long load is often not atomic: twenty-five of forty images sent, an export file half-written, a sync that already changed several local rows. After cancel stops what is unfinished, what happens to the finished stretch is still a state problem. Unsaid, people guess the cheapest model — everything voided, or everything kept — while the system is often a third thing: some kept, some rolled back, temp files still there. Stating the disposition is the close of cancel semantics, not courtesy.
Why it happens
Partial completion leaves traces in three places: remote (rows already written, quota already taken), local (cache, draft, temp files), UI (chunks already painted). Cancel aborts “continue”; it does not automatically pick a cleanup policy for those three. Policies include: roll everything back to before the start; keep what succeeded, drop what did not; mark the half-product as a resumable draft. None of these can be read from “wait chrome vanished”, because vanishing only encodes “stopped”. The world after stop needs a new status sentence: what was kept, what was dropped, whether work can resume.
The harm of not saying it is later actions built on a false premise. Thinking nothing uploaded, uploading again — duplicate. Thinking it uploaded, sharing — the file is a stump. Thinking the charge rolled back — the bill still has a line. Disposition copy turns cancel from negative progress into a complete state transition.
Where it stops holding
A pure read with no local trace can omit disposition copy; returning to the pre-cancel UI is the explanation. Same for a one-shot request with no partial (a whole replacement that had not started writing). The moment a partial could be seen by another session (a draft already on the server, a half-row already in someone else’s list), it must be said, even if the disposition is “withdrawn; the other party may have glimpsed it”. Rollback itself can fail; then the copy becomes “stopped continuing, but the written part could not be undone, deal with it here”, not a fake successful rollback. Do not cram retry-strategy detail into the disposition — that belongs with failure-and-retry. Here, only what the world looks like after this stop.
Applying it
- After a successful cancel, one status sentence: n items saved / no writes landed / temp file deleted / resume from draft.
- If a recoverable half-product exists, give an entry to it; do not only say “cancelled” and leave people to hunt a folder.
- If a remote partial may be briefly visible, admit the visibility window. Do not write “never happened”.
- How to check: cancel an upload or sync at 60% and ask someone nearby what is now on the server and what is local. If they cannot answer or answer wrong, disposition was not stated. Then check that actual traces match the sentence.