Context
Service Bus duplicate detection protects against repeated sends when the producer cannot tell whether an earlier attempt succeeded. The service can acknowledge a send and deliberately discard it because its MessageId was already seen. A successful send result therefore does not always mean a new queue entry was created.
Prerequisites are the queue or topic configuration, service tier, duplicate-detection window and producer message construction. Use a test entity for deliberate duplicate sends. Record business operation IDs, MessageId and relevant partition or session properties without copying sensitive payloads into diagnostic logs.
1. Establish the intended identity rule
Choose a MessageId that stays the same when retrying the same business operation. Generating a fresh random value for every attempt defeats send-side deduplication. Conversely, reusing one identifier for different legitimate operations can cause silent-looking loss from the producer's perspective.
Define where business identity starts and ends. An order-created event and a later order-cancelled event are different operations even when they share an order number. Include a meaningful operation discriminator when designing the identifier. Keep this rule consistent across producer versions and retry code paths.
2. Inspect the service detection boundary
Read the entity's enabled state and history window, and confirm the selected tier supports duplicate detection. The window is finite. Repeating the same identifier after it expires can create another message, so the feature is not a permanent business ledger.
Check partitioning and session configuration. When partitioning is enabled, the documented uniqueness rule includes MessageId and PartitionKey. Scheduled messages also participate in duplicate detection. A scheduled send can suppress a later immediate send with the same effective identity during the window. Review batching limitations for the chosen configuration.
3. Keep receive-side processing safe
Producer deduplication does not prevent a consumer from receiving an existing message again after lock loss or interruption. Use business idempotency at the consumer's commit boundary. Keep the producer's detection strategy and consumer's effect ledger as related but separate controls.
Test ambiguous send handling with bounded retries and the same identifier. If the application needs a legitimately new operation, generate its intended new business identity rather than changing identifiers only to force an unexplained message through. Investigate whether an earlier operation already completed before issuing a replacement.
Diagnostic checkpoints
| Evidence | Interpretation | Next check |
|---|---|---|
| Send succeeds, no new entry | Possible duplicate discard | Prior MessageId and window |
| Retries create many messages | IDs change across attempts | Producer retry construction |
| Scheduled send affects immediate send | Shared detection identity | Scheduled message record |
| Consumer repeats an effect | Delivery duplication | Receive-side idempotency |
Illustrative scenario
A hypothetical scheduler sends a reminder for tomorrow, then an operator issues an immediate replacement using the same MessageId. The immediate send is accepted but discarded within the detection window. The design review clarifies reminder identity and cancellation behavior. This fictional example does not imply that Service Bus lost an acknowledged unique message.
Verification and messaging SOP
In a disposable entity, send one operation twice with the same intended identity and another with a new identity. Verify the expected deliveries. Include partition properties and scheduled sends in the test matrix. Then separately test consumer redelivery safety.
Maintain the MessageId format, history-window rationale and producer compatibility rules in the SOP. Monitor producer acknowledgements alongside business completion records. Review identifier changes as a contract migration: old and new producers operating together must agree on what constitutes the same operation during retries.
Explore Clouvenix cloud architecture for implementation and operational handover.