Subscriptions failing to forward to an entity removed and reinstated with the same Name and properties

[asos-richardevans]

Description

We have had this issue investigated by MS support (2401020050003122) and it determined that the 'Forward To' Queue or Topic for a Subscription is stored as a ResourceId and not by the 'Name' property, which is used to view and set this value.
Consequently, should a resource be removed and reinstated with the same name, any subscriptions originally set to Forward To the resource has it's messages dead lettered with a 'The transfer destination entity does not exist.' error because the recreated resource now has a new ResourceId. Changing a property on the subscription updates the ResourceId used under the covers to point it to the new entity but until that is done all messages are dead lettered (Work around when you realise what's going on).

Actual Behavior

1. Create target Topic or Queue
2. Create a source Topic and subscription to forward to the target Topic
3. Remove the target Topic
4. Create the target Topic with exactly the same properties (as in step 1)
5. Send messages to the source Topic which meet the subscriptions rule
6. Messages are dead lettered not forwarded

Expected Behavior

1. Create target Topic or Queue
2. Create a source Topic and subscription to forward to the target Topic
   Either
3. Prevent removal of the target Queue/Topic (if queues or subscriptions are set to forward to it) as it essentially orphans the subscriptions, or at least warn about the consequences if the target entity is used by other entities.
   or
4. When creating a Topic with exactly the same properties (as in step 1), see if this is replacing a previously removed entity (I appreciate this would be more difficult if each entity only has a ResourceId to identify it and not the name as well - as appears to be the case).

[SeanFeldman]

@asos-richardevans, could you share the method used to create the entities (ARM/Bicep, Terraform, Management SDK, other SDK, etc.)?

When using the old SDK (track 0) to create the entities and set up auto-forwarding, the auto-forwarding still works when removing the forwarded to the destination entity and re-creating it. So, it depends on how the entities are created. You can validate that with the ServiceBus Explorer tool.

PS: There's a short period of a couple of seconds when the message sits in the source entity but is then auto-forwarded to the destination.

[asos-richardevans]

Hi @SeanFeldman,

The target Topic is created using Bicep and the source Topic & Subscription by ARM. Both using apiVersion 2017-04-01.

I am then using the Service Bus Explorer tool to 'touch' the source subscriptions properties to get it to update the ResourceId to which it forwards to. Otherwise, once the target Topic is removed no messages are forwarded (only dead lettered) even after a Topic with the same properties of the original target Topic is recreated (using the same Bicep template) as although the target Topic is identical to the one deleted, it has a new ResourceId (which I can't see) and the source Subscription still points at the old ResourceId for the purposes of identifying the entity to forward messages to.

[EldertGrootenboer]

Thank you for your feedback. We have opened an investigation task for this in our backlog, and will update this issue when we have more information.

[EldertGrootenboer]

This item in our backlog, however we currently don't have an ETA on when development might start on this. For now, to help us give this the right priority, it would be helpful to see others vote and support this item.

[lukecalderon]

Can confirm we have experienced the same issue today, with subscriptions created in April 2024.

They were created with Terraform, using the AzureRM provider version 3.97.0.

The workaround suggested by @asos-richardevans worked for us (re-selecting the auto forward to queue and saving). Interestingly we didn't see this in a separate tenant/subscription, which was created around the same time with the same TF provider version.