Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
asos-richardevans opened this issue Jan 25, 2024 · 4 comments

Comments

@asos-richardevans
Copy link

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
Copy link
Contributor

SeanFeldman commented Jan 25, 2024

@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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants