Cleanup can be an idempotent postcondition

A useful API can make a routine absent-state condition ordinary. The service26 owns the postcondition instead of requiring every caller to catch and ignore it.

Rather than throwing an error when unset is asked to delete an unknown variable, it should have simply returned without doing anything.

Source: Q1633; B1033.

Failure it prevents

Cleanup accumulates special cases and fails on harmless repeated execution.

Our Effect 4.0.0 reading

Typed failures39 do not require exporting avoidable errors. Put the domain meaning in the service contract27; Effect29 supplies execution. The domain defines the postcondition.

Source: packages/effect/src/Effect.ts, packages/effect/src/Context.ts.

How to check

Run cleanup twice. Require the same intended result, while preserving meaningful permission or storage failures. This check is our proposal. The books do not prescribe it.

Continue with Retry needs idempotent effects14, Failures keep their meaning10.

Connect this to the existing rat-stack guidance39.

Use the durability skill for the full review. Return to the durability index34.

Sources

  1. Ousterhout, John. A Philosophy of Software Design. 2018.. John Ousterhout. §4.4 Deep Modules; §10.2 Too Many Exceptions; §10.3 Define Errors Out of Existence; §10.6 Mask Exceptions; §10.7 Exception Aggregation; §10.8 Just Crash?; §10.10 Taking It Too Far. Accessed 2026-10-23.
  2. Effect contributors. Effect 4.0.0. Effect.ts. Effect-TS. Pinned source for our Effect mapping, not a claim from the book. Accessed 2026-10-23.
  3. Effect contributors. Effect 4.0.0. Context.ts. Effect-TS. Pinned source for our Effect mapping, not a claim from the book. Accessed 2026-10-23.

Last changed 2026-10-23 in 58dc623. Source on GitHub. Change log.

Linked from

  1. Agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.

    Cleanup can be an idempotent postcondition — Already-absent state can be success when absence is the operation’s intended result.

  2. Change log. What changed in the files served here, newest first.

    Cleanup can be an idempotent postcondition — new page: docs(lore): land the durability wiki pages and bibliography

  3. durability. Keep a rat-stack app standing when a provider, pool, or dependency slows down or a worker dies. Use at any I/O boundary, connection pool, provider call, shared waiter, fan-out, flag, gate, or work that can outlive a request, or when asked "what happens when this is slow", "add a timeout", "make this durable", or "what survives a crash".

    3 Define Errors Out of Existence.

  4. Durability bibliography. Books, checked short quotations, source limits, and Effect mapping provenance.

    3 Define Errors Out of Existence¶

  5. Durability starts with a recovery record. A reading order for storage, replay, worker ownership, overload, and recovery tests.

    Cleanup can be an idempotent postcondition: Already-absent state can be success when absence is the operation’s intended result.¶

  6. Failures keep their meaning. Expected refusals, infrastructure faults, and defects need different policies.

    Continue with Cleanup can be an idempotent postcondition, Pure cores reduce timeline coupling.¶

  7. Full agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.
  8. Rat Stack lore | rat-stack. Short, source-grounded notes on the ideas and decisions behind rat-stack.

    Cleanup can be an idempotent postcondition — Already-absent state can be success when absence is the operation’s intended result.

  9. Retry needs idempotent effects. Repeating an operation must preserve its intended observable result.

    Continue with Checkpoints follow the promised commit, Cleanup can be an idempotent postcondition.¶

  10. Source change history (log.md). The generated change log as Markdown.

    Cleanup can be an idempotent postcondition — new page: docs(lore): land the durability wiki pages and bibliography