Idempotency

Idempotency is the property that processing the same message twice leaves the System in the same state as processing it once. It exists to make retries safe: recovery in an Intropy System works, at every level, by delivering a message again, so a Component with side effects must be able to receive the same message twice without doubling its effect.

Why duplicates are normal

Three ordinary events deliver the same message twice. The runtime retries a technical failure, and the retried message may have completed its side effect before the failure hit. The message broker redelivers when an acknowledgement is lost. An operator replays an earlier run to backfill after an outage. All three exist because delivery is at-least-once: when in doubt, a message is delivered again rather than lost.

The framework therefore treats “already processed” as an expected outcome, not an error. An idempotency check near the front of the pipeline answers Cancelled for a duplicate: the remaining steps are skipped and the run completes as a traceable no-op.

Without the check, the runtime would have to choose between duplicated side effects and discarded messages every time an infrastructure call failed. With it in place, a message can be retried and replayed freely, and the Component still produces its business effect at most once.

What counts as the same message

The check compares three things about each message:

• An id that names what the message is about. The id is configurable, and the check doesn’t care what kind it is — only that the same thing carries the same id on every delivery. A business identifier (an order number, a customer number) usually has that property; a value minted fresh per delivery does not.
• A hash of the content, so the check can tell a plain redelivery from an updated message carrying the same id.
• A timestamp, so when several versions of the same id are in flight — retries, replays — the check knows their order, and a stale version can’t win over a newer one.