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.
> 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.
