Resubmit deadletter message to subcription RRS feed

  • Question

  • Hi

    We have a scenario where a message fails multiple times for a particular subscriber and is sent to the deadletter queue. Particular deadletter messages we want to resubmit to the particular subscriber at a later time.

    I cannot see a way to do this. I try to resubmit to the subscriber's queue doing something like the following:

    var subscriptionPath = SubscriptionClient.FormatSubscriptionPath(topicName, subscriptionName);
    var client = QueueClient.CreateFromConnectionString(connectionString, subscriptionPath);

    But this causes an Invalid Operation exception with message Cannot open a Queue client for entity type Subscriber.

    I'm able to resubmit it to the topic, but that means all subscribers receive it, so I don't want to do this.

    How do I do this? If I'm not able to, what is recommended instead?


    Thursday, May 28, 2015 3:39 AM


All replies

  • Of course you can't send message to a subscription but only to a topic.

    A topic is an "input point" for the service bus and subscription is an "output point".

    IMHO, The only way you have is to re-submit to the topic and set a custom property in the message to alert all the receiver that it is a re-submission. It's up to you choose the property and eventually use a filter on the subscription or a check inside the business code.


    Paolo Patierno

    Thursday, May 28, 2015 8:58 AM
  • Have you tried incresing MaxDeliveryCount on the subscription? If you don't want your messages to get dead-lettered then you can basically set it to "0".


    Thursday, May 28, 2015 6:37 PM
  • Paolo - Yes except the message completes on all other subscriptions bar one, not on the topic. It makes sense to me to republish to that subscription only if we expect it to no longer fail.

    Since we don't want the message to be published to all subscribers again it sounds like the way forward is to avoid resubmitting.

    Thursday, May 28, 2015 11:42 PM
  • Serkant - in scenario's where the subscription is for a system that is down for 12 hours, we want it to deadletter, then process the deadlettered messages when the system is back up.
    Thursday, May 28, 2015 11:44 PM
  • One option is to use SQL filters on the subscriptions. This way you can control which subscription your message will land on. Here's is an example with 2 subscriptions.

    SubscriptionA with Filter = "Not EXISTS(target) OR target='subA'"

    SubscriptionB with Filter = "Not EXISTS(target) OR target='subB'"

    When you need to resend dead-lettered messages just add a new property "target" with destination subscription.

    Friday, May 29, 2015 1:00 AM
  • Serkant - thanks for pointing me to this thread.  Your suggestion would work, but this makes for a messy solution when you are building a messing-based microservice architecture with dozens if not hundreds of topics and subscriptions, and one needs to plan ahead for the possibility that any subscriber to any topic could need to reprocess a message from its dead letter.  As I mentioned in my other post, every other messaging broker I have experience with has a relatively simple solution to this problem - you just re-enqueue the message on the subscription queue that it failed from.  I would suggest that this should be considered a design flaw or a gap in the this messaging broker's capability.
    Thursday, June 4, 2015 10:59 AM
  • By design Service Bus subscriptions are receive-only queues hence you cannot send to them and also we currently don't have a way of restoring dead-lettered messages back to its queue.

    I suggest you to add this feature request on http://feedback.azure.com/forums/216926-service-bus

    • Marked as answer by Steve K - SCC Wednesday, May 17, 2017 2:33 AM
    Thursday, June 4, 2015 6:53 PM
  • This feature is one of the show-blocker for us to get our queue to production. While I am on the hunt, I found this tool Serverless360 which provides this capability out of the box where I can resubmit the messages to the Subscription by just defining Topic Subscription Rule in it.

    Monday, February 3, 2020 2:09 PM