Proper way to handle dead-lettered messages using Dapr ?

[shut dragon]

Hi. Let's say we have 3 different services subscribing to the same topic. All 3 services have their own dead-letter queues for that topic.
Service 2 fails to process the message and it lands in the dead-letter queue.
Using Dapr is there a way to publish that message back to the queue of service 2?
As I see we can publish the message back to the topic but that would make the other 2 services consume the message again.
I guess one way would be to publish it to the topic again and rely on the consumers being idempotent, but I'm trying to avoid that scenario.
How do you handle such scenarios?

[shut dragon]

I guess the limiting factor for Dapr possibilities are simple pub/sub solutions, like Redis, but anyway would be great to hear how you approach these cases.

[shut dragon]

I'm thinking of republishing to the topic but will introduce an optional property that allows for targeting a specific service and drop the message when received at other consumers that are idempotent as well

[ocean laurel]

If it's in a dead letter queue and especially a separate one for each service, and all services are subscribing to the same topic, 1) unless you're using routing, I don't know how you would guarantee that service 2 ever reliably gets the message over another service and 2) or any other service see it without republishing into the queue.

If you only intend that one specific service do anything with the message in the first instance, I would advise using routing from the start so you avoid the requeue in the first place

[shut dragon]

Thanks @ocean laurel

• So a service is a WebApi which can have 1 or more instances.
• Multiple WebApi's may subsribe to a single topic, ie: auth-service-topic
• Each WebApi has it's own dead-letter queue. ie: orders-service-dead-letter, inventory-service-dead-letter.
• Internally each WebApi is using routing by cloudevent type to filter events it's interested in, like when subscribing to auth-service-topic, it is not interested in all events but filters them by type.

Eventually I solved the DLQ so that I will manually publish the dead-lettered message back to the topic, as I cannot directly target the WebApi queue using Dapr.
That will make all the WebApis receive the message again, but this time the message will have a "recipient" field set so only that specific WebAPi will process it, the other consumers will discard it as the recipient is explicitly set.
Also all consumers are idempotent, so they will not double process the same message, which is the 2nd line of defense 🙂

[ocean laurel]

That's right, but also note that unless you're specifying it yourself (on some pubsub components), Dapr will automatically assign consumerID to your PubSub topic, so only one of your apps will receive each message.

Read the blurb next to consumerID for Azure Service Bus Topics, for example: https://docs.dapr.io/reference/components-reference/supported-pubsub/setup-azure-servicebus-topics/#spec-metadata-fields

[shut dragon]

Thanks. How I understand it is that WebApi1 instances will have the same consumerId (ie web-api-1) so only one instances will process a message, and the same for WebApi2, WebApi3 instances. But we'll have 3 subscriptions to the topic, each one with its own queue.. At least that's how it behaves using RabbitMQ : )

[ocean laurel]

That's right

[shut dragon]

👍 thanks