Cleaning up deferred messages on Azure Service Bus without the sequence number

Question

Is there any way to recover or delete a deferred message on Azure Service Bus if I've lost the sequence number?

The scenario is: I want to use BrokeredMessage.Defer() to defer a message. I plan to record the sequence number, and use it later on to retrieve the message. But if something goes wrong — let's say some buggy code is deployed — and the sequence number is not recorded properly, it seems like that message will sit on the service bus in a deferred state until the message expires, which could be forever.

This concerns me primarily because that message will occupy space on the queue or subscription, and I haven't found any way of recovering that space short of completely deleting the queue/subscription.

Is there any way to either receive or delete "lost" deferred messages?

Answer 1

Peeking messages from a queue or subscription will also return deferred messages. Deferred messages will have State = "Deferred".

This way you can get the sequence numbers of the deferred messages and afterwards process or delete these messages.

You can try this out in ServiceBus Explorer:

Answer 2

As to preventing orphaned deferred messages because of lost sequence numbers, you should build resiliency into the storage process where you maintain them, perhaps with another queue. In other words, when you defer a message, create a message in another queue or topic to store the deferred sequence number, or the entire message (cloned).

I typically move all deferred messages to my own "deferred topic", and handle them separately. In other words, my own custom deferral logic, avoiding the problem altogether. If the auto-timeout logic does not work in your scenario (BrokeredMessage.TimeToLive), this may be a better route for you.

This article does a good job of partially explaining your scenario, using a special overload of Queue.Receive:

http://markheath.net/post/defer-processing-azure-service-bus-message

Since you are storing the sequence number (in a resilient way :-)), another alternative would be to store the entire message (JSON, property bag, etc.), and resubmit it when you want to process it again (from another queue, perhaps).