Retry Mechanism in Dapr PUB/SUB
KrzysztofPajak opened this issue · comments
Ask your question here
I wanted to bring up an issue I've encountered while utilizing Dapr's PUB/SUB functionality, particularly regarding the retry mechanism.
In my application, I use Dapr for PUB/SUB messaging, with Azure Service Bus handling message delivery. The issue arises when attempting to retry messages upon receiving a 400 error code. These errors typically indicate that the data sent to my application is invalid, and as such, I reject such requests. However, depending on the retry settings in Azure Service Bus, the system retries the message, leading to subsequent failures. Similarly, configuring resiliency in Dapr also results in retries.
While I understand that retries should occur in the case of 5XX errors, in my scenario, additional retries only generate unnecessary traffic. Is there a mechanism available within Dapr that can move such messages to a dead letter queue based on the error code? Alternatively, are there any other configuration options in Dapr that could mitigate this unnecessary load?
I truly appreciate any assistance or guidance you can provide on this matter. Thank you for your support and for the excellent product that is Dapr!
Returning a JSON body with the 400 response with { "status":"DROP" } should cause the messages to drop. If you'd like more detailed help, please post the configuration for your pub/sub component and resiliency and people can take a closer look.
@Flern Using DROP will delete the message. My intention is to move the message to the dead letter so that it won’t be retried. In the case of 5XX errors, messages can be retried because it’s unclear what caused the processing failure.
I would try combining your resiliency policy for retires with a dead letter topic declaration on the subscription configuration.
See https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-deadletter/ for examples.
I'm not sure how this pays with Azure Service Bus, and I have no idea how you have the pub sub currently configured, but it's the best I can do
Using Retries and Letter topics, it must execute as many times as defined.
I found a similar thread here #7132
That would solve my problem
As it stands, you can only force a message to the Dapr-provided Dead-Letter Queue via the DROP semantic response.
I believe the problem here is that there is no explicit way to force a PubSub message to the native Dead Letter Queue of a broker (if the broker has a native DLQ)
It's been talked about at length in this thread #4917