Skip to content

Retry Mechanism in Dapr PUB/SUB #7697

Closed as not planned
Closed as not planned
@KrzysztofPajak

Description

@KrzysztofPajak

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleIssues and PRs without response

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions