No error or status code indicates duplicate detection drop in Azure Service Bus

Direct answer

The Azure Service Bus duplicate-detection cache does not survive a full namespace restart. It is an in-memory structure maintained by the broker, so any message IDs tracked during the previous duplicate-detection window are lost when the namespace restarts. A retried message with the same ID will be accepted as a new message.

Pausing a queue or topic does not clear the cache. Existing IDs remain frozen in place until the entity is resumed, after which normal expiration resumes.

Scaling a partitioned queue or topic creates new broker nodes. The cache is not merged across partitions, so an ID tracked on the original partition is not visible to the new partition. This can allow duplicate deliveries after a scale operation.

After a broker node failure, surviving replicas retain the cache for the remainder of the window. If the failed node is not replaced quickly, tracked IDs may be lost.

Confirmed behavior vs. configuration-dependent risk

Confirmed:

• No error, status code, or dead-letter path is emitted when duplicate detection suppresses a message. The message is silently dropped.
• The cache is volatile; it is not backed by durable storage.

Configuration-dependent:

• Tier: Standard uses a single message broker; Premium uses partitioned brokers. The blast radius of a restart or node failure differs.
• Window: The default duplicate-detection window is 10 minutes and can be extended up to 7 days. A longer window increases the expectation that IDs are still tracked, but it does not make the underlying store durable.

Verification steps

1. Check the Azure Monitor metric for messages dropped by duplicate detection before and after a restart. If the counter resets or the expected drops stop appearing, the cache was lost.
2. Enable diagnostic settings on the namespace and inspect duplicate-detection tracking logs to confirm whether previously seen IDs are still present.
3. Confirm the current duplicate-detection window with the Azure CLI:

   az servicebus namespace show \
     --resource-group <resource-group> \
     --name <namespace> \
     --query duplicateDetectionStatus

One missing detail that changes the recommendation

Which Service Bus tier are you using (Standard or Premium), and what is the configured duplicate-detection window? On Premium with partitioning, a restart or scale event can leave stale IDs on some partitions and fresh state on others. If you are on Standard, the entire cache is lost on restart. Knowing the tier and window determines whether you need an application-level idempotency store as a backstop.