No All-or-Nothing Fiction

"You cannot atomically move two hundred files across a volume. Pretending you can is how you lie to a user at the worst possible moment."

The Atomicity a Multi-Item Op Cannot Have

A single same-volume rename can be atomic. Two hundred file copies across a network share cannot — physically, they happen one after another over real time, and time is interruptible. So an app has a choice when item 137 fails: tell the truth (136 are done, one failed, the rest are pending) or tell a comforting fiction (roll it all back so it looks like nothing happened). Waygate always tells the truth, because the fiction is where data gets lost.

Why the Rollback Fiction Is Dangerous

To present a 200-item move as atomic, a failure at 137 would force you to un-move 136 files that legitimately, verifiably arrived at their destination — re-deleting and re-copying real, correct files just to maintain an illusion. Every one of those reversals is a fresh file operation that can itself fail or hit a collision. You'd be doing 136 more risky mutations to pretend the first 136 never happened. The 'clean' rollback is more dangerous than the honest partial state.

What Waygate Does Instead

Completed items stay completed, each with its own journal evidence. The operation stops before the affected item — it doesn't skip ahead and it doesn't roll back. The user sees exactly what finished, what stopped it, and what remains, and the remainder can be re-planned against current reality. A multi-item operation is a sequence of individually-journaled steps, not a single magic transaction, and honesty about that is a safety feature.

A multi-item operation is never presented as globally atomic. Every item transition is journaled, completed items remain completed, and uncertainty stops the remaining plan for review. Faking all-or-nothing would mean reversing verified work — more risky mutations to sustain an illusion — so Waygate reports the true partial state instead.

This one took me a while to accept. My instinct was that a half-finished batch is 'messy' and a clean rollback is 'professional.' Dad flipped it: the rollback is the amateur move, because it does more destructive work to protect a feeling. The professional move is an honest ledger — here's what's done, here's where it stopped, here's what's left. A file manager that tells you the truth about a partial failure is worth more than one that hides it behind a lie of atomicity.

Code

Per-item journal; stop at the problem, keep what's done·swift

func runMultiItem(_ plan: OperationPlan) async throws -> BatchOutcome {
    var done: [ItemResult] = []
    for item in plan.items {
        do {
            let result = try await engine.runItem(item, plan)
            try await journal.mark(plan.id, .itemCommitted(item.id), evidence: result)
            done.append(result)                     // completed STAYS completed
        } catch {
            try await journal.mark(plan.id, .stoppedAt(item.id), error: error)
            // Do NOT roll back `done`. Do NOT skip ahead. STOP and report:
            return BatchOutcome(completed: done, stoppedAt: item, remaining: plan.after(item))
        }
    }
    return BatchOutcome(completed: done, stoppedAt: nil, remaining: [])
}

Exercise

A tool moves 500 files and fails at 300 with a full destination disk. Compare two designs: (A) roll back the 299 completed moves to look atomic; (B) keep the 299, stop, report. For each, count how many additional file operations run after the failure, and how many new chances there are to lose data. Which is actually safer?

Hint

Design A runs 299 reversals — re-deleting and restoring files that were fine — each a new operation that can fail on the already-full disk, potentially stranding files mid-reversal. Design B runs zero additional mutations: it just records the truth. B is safer precisely because doing nothing to verified work can't corrupt it. Honesty is fewer moving parts.

The Atomicity a Multi-Item Op Cannot Have

Why the Rollback Fiction Is Dangerous

What Waygate Does Instead

Code

External links

Exercise

Progress

Comments 0