Stacked optimistic steps need a defined rollback radius

What it is

Someone does several optimistic acts in a row: retitle, then tag, then post a comment. One step in the middle is refused. Which acts should rollback peel off? Rollback scope is a boundary declared in advance: this step only, later steps that depend on it, or the whole chain. When the scope is vague the UI peels the wrong layer — a comment that did not fail vanishes with it, or a failed title stays and tags built on the wrong title stay too.

This leaf is not whether a single-step rollback sits cleanly; that is placement. Here it is the radius among steps.

Why it happens

Each optimistic step opens a new branch on the previous result. Steps have dependencies: a comment “reply to that line” depends on the line still existing; a tag “add to this piece” depends on the piece’s identity still existing. One step fails, later steps that depend on it have no foundation in the real world; keeping them on screen turns the later ones into lies as well. Conversely, steps orthogonal to the failed one (another record) being taken down with it turns one refusal into collateral.

Scope is therefore not a taste for “roll everything back” or “keep everything”. It is a closure on the dependency graph. The product has to have a graph, even a shallow one: later writes on the same object depend; writes across objects do not. Without a graph, implementations tend to “rewind everything whose time is after the failure” — sweeping orthogonals — or “rewind only this field”, leaving later work built on the failed result as ghosts.

Where it stops holding

Fully independent optimistic acts (starring three different mails) must not touch the other two when one fails. A wizard whose every step already submitted to the server may find later steps already true on the far side; the radius is then refused by the server: “the later ones already happened, you cannot rewind them only on screen”. Scope then has to say “the screen returns to the failed step, and names the fate of later steps on the far side”, not pretend the chain can rewind. In collaboration, someone else started a body on your optimistic title; rolling the title back becomes their conflict, and the radius has left your session. A batch “archive all selected” is one step, not N stacked; some messages failing is partial batch failure, another kind of scope (which items), not step-closure.

Applying it

• Give consecutive optimistic acts dependencies: a later step names which unconfirmed write it sits on. On failure, roll back that write and its dependent closure only.
• Let the UI show which items this rollback took (“title not saved; two tags based on it undone”). Do not only vanish without a count.
• Do not use “everything after the failure” as the map. Orthogonal acts must live.
• How to check: optimistic retitle, immediately optimistic two tags, then an optimistic comment. Fail “add tags”. Title and comment should remain (if they do not depend on tags); both tags should go. Then fail “retitle”: later work that depends on the title text should roll with it; an already-sent comment unrelated to the title should not vanish. Fail one step at a time, list what was taken, and reconcile with the graph.

Related

• Same group: I3.09.1 Rollback must restore the pre-failure UI, not leave a pending ghost · I3.09.3 A rollback notice must say why it failed and whether retry is possible · I3.09.4 Don't commit later decisions to an unconfirmed optimistic result
• Nearby: I3.02 Optimistic updates · I3.13 State-machine completeness and illegal states
• Search terms: rollback scope · stacked optimistic · dependency closure