Verifying handler idempotency Added in 1.7.0
Decide whether a Wolverine handler actually needs to be idempotent, and verify that it is. Scopes the problem by endpoint mode (Durable users mostly do not need this; NativeAck users do, by design), quotes the measured duplicate rates rather than hand-waving, covers what the in-memory idempotency guard does and does not buy, explains that Wolverine's own idempotency only ever dedups a repeated Wolverine message id (Eager vs Optimistic checking, why EF Core only does Eager, and the MessageIdentity.IdAndDestination fan-out trap), and gives a concrete two-run test recipe with the traps that make such a test pass while the handler is still not idempotent.
Use when asked 'is my handler idempotent?', 'do I need to change my handlers for NativeAck?', or when diagnosing duplicated side effects, double charges, repeated cascading messages, or messages silently discarded as duplicates.
Skill details
- Skill name:
wolverine-messaging-handler-idempotency - Applies to:
wolverine - Tags:
messaging,idempotency,duplicates,native-ack,testing,delivery-guarantees,endpoints - Added in: 1.7.0
- License: Proprietary. Copyright JasperFx Software LLC.