Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retry Mechanism in Dapr PUB/SUB #7697

Open
KrzysztofPajak opened this issue Apr 15, 2024 · 5 comments
Open

Retry Mechanism in Dapr PUB/SUB #7697

KrzysztofPajak opened this issue Apr 15, 2024 · 5 comments

Comments

@KrzysztofPajak
Copy link

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!

@Flern
Copy link
Contributor

Flern commented Apr 19, 2024

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.

@KrzysztofPajak
Copy link
Author

@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.

@Flern
Copy link
Contributor

Flern commented Apr 19, 2024

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

@KrzysztofPajak
Copy link
Author

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

@olitomlinson
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants