[d4rkn0d3z]

We are saying the same thing using different words. I view this as a strategy for dealing with a lack of idempotency in handlers with a great deal of overhead. So I guess I would call it a non-idempotency key since a handler that is not idempotent will necessarily use it. I think this strays too close to a contradiction in terms.

[vouwfietsman]

Maybe this is a mismatch of expectations, but I generally think very few handlers are idempotent without such a key. E.g any edits or soft-deleted are impossible to handle in an idempotent way without auxiliary information (idempotency key or timestamp or sequence number).

[d4rkn0d3z]

Again stopping the execution of the handler based on an ID is not idempotency, but rather a corrective measure due to the fact that the handler is not idempotent. Idempotency is a property that says the handler can run as many times as I like, as diametrically opposed to the notion that it can run only once.

[vouwfietsman]

No, its a matter of perspective.

> Idempotency is a property that says the handler can run as many times as I like

.... using some input. If that input has a key and the handler bails on execution, your definition is not at all violated. Its only violated if you don't consider the check a part of the handler, which is an arbitrary limitation.

Regardless, I think your interpretation that avoids identifying the message explicitly leaves a very narrow set of idempotency candidates, which is not a useful definition. Under that definition, really only reads are idempotent, as any state setting can be later retried and give a different result if other state settings are interleaved.