I have a question about suggested strategies for dealing with Dead letter queues for Topic subscriptions. The situation we have is this:
Our service has a Subscription to a Topic that another team owns and is publishing too. For that reason, our service has Listen permissions for the Topic (i.e. not Send)
We have "Max Delivery Count" for our Subscription set to 10. What we observe is that after ten failed attempts to process a message, that message goes to the DeadLetterQueue(DLQ) for our Subscription. All as expected.
We now want to have a mechanism where we can attempt to re-process the messages on the DLQ, and we are trying to figure out the best strategy for doing so.
Our initial naive thought(I'll call it "Option A") was to pull the messages from the DLQ, read the values of the message, and then create and publish a new Message to the Topic(and remove that message from the DLQ). However, this is problematic
for a couple of reasons:
1) We don't have Send permissions to the Topic, so we can't do that right now
2) Even if we could get Send permissions, if we re-published a message to the Topic as a whole, every Subscriber to that topic would have to see and deal with that re-published messages. This seems inefficient and problematic. (And yes, we do
understand that due to the nature of things, all services do need to be able to handle duplicate messages anyway, but still feels wrong)
We are brainstorming several other options, but I'm curious if Microsoft or others have recommendations or experience dealing with this scenario and could give thoughts and advice.
Thanks
Mike