What's the actual difference between idempotency and "safe to re-run" — can a task be safely re-run without actually being idempotent?

Idempotency is a precise property: running an operation multiple times produces the exact same end state as running it once, with no accumulating side effects. "Safe to re-run" is a weaker, more practical guarantee: re-running doesn't cause harm, even if the operation isn't strictly idempotent — for example, a task that's safe to re-run because it's guarded by a check, or because its side effects are genuinely harmless to repeat (like re-sending an already-delivered notification that's merely redundant, not damaging). Every idempotent operation is safe to re-run, but not every safe-to-re-run operation is actually idempotent.

Idempotency, precisely defined, means f(f(x)) = f(x) — applying an operation twice has the same effect as applying it once. INSERT INTO users ... is not idempotent (running it twice creates two rows); UPDATE users SET status = 'active' WHERE id = 5 is idempotent (running it any number of times leaves the row in the same final state). This is a statement about the end state being identical regardless of how many times the operation ran, not merely about the operation being harmless to repeat.

"Safe to re-run" is a broader, more pragmatic category that includes idempotent operations but also includes operations that aren't idempotent by the strict definition yet still cause no real harm when repeated. A few distinct ways an operation can be "safe to re-run" without being idempotent: it might be guarded by an explicit check (if not exists, then create — the overall task is safe to re-run because the guard makes repeated execution a no-op after the first success, even though the underlying create action itself isn't idempotent in isolation); its side effects might be genuinely inconsequential to repeat (re-running a script that only reads data and writes to a log file is "safe" in the sense that nothing breaks, even though the log file technically grows differently each time — not truly idempotent, but harmless); or it might be safe specifically because of how it's orchestrated (a deployment step wrapped in a distributed lock that prevents concurrent re-execution is "safe" due to the lock, not because the underlying operation is idempotent).

This distinction matters practically because "safe to re-run" is a weaker guarantee that depends on context — a task that's safe to re-run in isolation might not be safe to re-run concurrently with itself, or safe to re-run after a partial failure left the system in an intermediate state that the guard-check doesn't account for. True idempotency doesn't have these edge cases: by definition, no matter what state the system is currently in as a result of prior runs, running the idempotent operation again converges to the same target state. This is exactly why infrastructure-as-code tools and configuration management tools aim for genuine idempotency in their primitives rather than relying on "probably safe to re-run" — it removes a whole category of reasoning about partial-failure edge cases that a merely-safe-to-re-run task still carries.

• Idempotency is precise: running an operation any number of times produces the same end state as running it once.
• "Safe to re-run" is broader and includes idempotent operations plus non-idempotent ones made harmless by guards, inconsequential side effects, or orchestration (like locking).
• Every idempotent operation is safe to re-run; the reverse isn't true.
• "Safe to re-run" guarantees are often context-dependent (concurrency, partial-failure state) in ways true idempotency isn't, which is why infrastructure tooling aims for genuine idempotency rather than merely-safe repetition.

• Ansible: Idempotency and check mode
• Terraform: State and drift