principle-make-operations-idempotent

Make an operation idempotent by designing it to converge to the correct end state no matter how many times it runs or where it starts. Scan for existing state at startup, clean stale artifacts, and add a reconciliation step wherever leftover state would change the outcome.

Handle crashes by making failed work respawn cleanly and regenerating fresh input after each cycle. Use idempotent scheduling so a retried item produces the same result as a first attempt, regardless of what the crashed run completed.

A stale lock is a lock left behind by a process that crashed before releasing it. Detect it using PID-based checks: if the process ID recorded in the lock no longer corresponds to a live process, the lock is stale and can be safely reclaimed.

Use content-based cleanup whenever artifacts may be recreated or reordered across runs. Comparing by content equivalence ensures cleanup decisions stay correct even when a previous run crashed halfway or items were created in a different sequence.

Idempotency ensures convergence to the same end state but does not prevent side effects that are inherently non-repeatable, such as sending external notifications. Operations with irreversible external effects still need separate deduplication or compensation logic.