Enabling Duplicate Detection (requiresDuplicateDetection) on an existing service bus topic or queue.

Once a service bus topic or queue has been created, the setting (requiresDuplicateDetection) for duplicate message detection cannot be modified/set.

The following exception will be seen if the setting is attempted to be modified/set:

SubCode=40000. The value for the 'requiresDuplicateDetection' property of an existing Queue(or Topic) cannot be changed.

There are situations where you may want to enable or disable this feature for a given queue or topic after its creation.

Some options are below to help achieve this.

Options

There a couple of methods to work with when needing to update requiresDuplicateDetection:

Create a new queue/topic with duplicate detection and then forward from the original queue to the new queue/topic. (Recommendation from Service Bus Resource Manager exceptions)
Drop and recreate the queue/topic from templates (IaC templates; bicep, ARM, terraform, etc…)
Drop and recreate the queue/topic via service bus explorer standalone + IaC template updates.
Handle de-duplication elsewhere (upstream or downstream).

Option 1 is the listed recommendation against the error exception in the documentation. This does however suggest a permanent forward to a new queue/topic be in place. If this were to be used, if on the standard Service Bus tier, consideration should be given tocost as this will incur additional operations. If on the Premium tier, as the cost is hourly instead of per operation, this should not have any cost impact for service bus operations (excluding private link, network traffic if private, diagnostic logging, etc…).

Option 2 is the ideal as it achieves using the service bus feature for duplication, but has the greatest impact for inflight services and usage. On top of this, if SAS keys are in use, recreating the topics or queues will cause new keys to be generated, which can be an additional burden. If RBAC is in use, the roles will stay in place.

Option 3 is a variation of 2, but includes "recreating" the queue/topic via the standalone service bus explorer application. This has a side benefit of keeping the existing SAS keys and achieving "updating" the requiresDuplicateDetection. You can also keep the IaC templates up to date with the new setting. The application of the setting for the first time is/must be via the service bus explorer standalone application import/export feature.

Option 4 needs greater consideration for the situation at hand, as either upstream application or API policy logic will need to cater for this (duplication), or downstream with the ability to deal with or process duplicate messages in an appropriate manner. It is still an option nonetheless.

Options Summary

Overall options 2 and 3 are the generic ideals, as it allows the feature to be set and enabled/disabled, without adding solution complexity (forwarding) that option 1 has.

If an outage can be sustained, option 2 is a good candidate for a clean result.Else option 3 to limit the outage time and keep all configuration the same.

These are outlined below.

Option 2

Update your IaC templates to set the requiresDuplicateDetection field to the required value (true or false).

Ensure all messages to the queue(s) or topic(s) being removed are stopped and drained. No messages present in the queue(s) or topic(s).

Remove the queue(s) or topic(s) from the service bus instance.

Deploy the IaC templates to re-create the queue(s) or topic(s).

Enable/allow messages to be sent to and from the queue(s) or topic(s).

Result: requiresDuplicateDetection updated, new SAS keys for all affected queue(s) or topic(s), RBAC left intact.

Option 3

Via the Service Bus Explorer Standalone application, export the queue(s) or topic(s) being updated.

In the exported files, update the requiresDuplicateDetection setting to the required new value (true or false).

Update your IaC templates to set the requiresDuplicateDetection field to the required value (true or false).

Ensure all messages to the queue(s) or topic(s) being removed are stopped and drained. No messages present in the queue(s) or topic(s).

Remove the queue(s) or topic(s) from the service bus instance via the Service Bus Explorer Standalone application.

Import the updated export file via the Service Bus Explorer Standalone application. This will re-create the queue(s) or topic(s).

Enable/allow messages to be sent to and from the queue(s) or topic(s).

Result: requiresDuplicateDetection updated, no other changes (SAS keys & RBAC left intact).

Final thoughts

All options should consider the solution and situation at hand. The recommend options above gives a path to use the service bus feature with the least amount of change and impact as possible.