Clarify: built-in pub/sub retry policies are not set by Dapr #4492
+2
−2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Hannah Hunter <[email protected]>
|
Stale PR, paging all reviewers |
marcduiker
requested changes
Jan 24, 2025
| @@ -38,7 +38,7 @@ If you don't specify a timeout value, the policy does not enforce a time and def | |||
| With `retries`, you can define a retry strategy for failed operations, including requests failed due to triggering a defined timeout or circuit breaker policy. | |||
|
|
|||
| {{% alert title="Pub/sub component retries vs inbound resiliency" color="warning" %}} | |||
| Each [pub/sub component]({{< ref supported-pubsub >}}) has its own built-in retry behaviors. Explicity applying a Dapr resiliency policy doesn't override these implicit retry policies. Rather, the resiliency policy augments the built-in retry, which can cause repetitive clustering of messages. | |||
| Each [pub/sub component]({{< ref supported-pubsub >}}) has its own built-in retry behaviors, unique to their third party and not set by Dapr. Explicity applying a Dapr resiliency policy doesn't override these implicit retry policies. Rather, the resiliency policy augments the built-in retry, which can cause repetitive clustering of messages. | |||
There was a problem hiding this comment.
Suggested change
| Each [pub/sub component]({{< ref supported-pubsub >}}) has its own built-in retry behaviors, unique to their third party and not set by Dapr. Explicity applying a Dapr resiliency policy doesn't override these implicit retry policies. Rather, the resiliency policy augments the built-in retry, which can cause repetitive clustering of messages. | |
| Each [pub/sub component]({{< ref supported-pubsub >}}) has its own built-in retry behaviors, unique to the message broker solution and unrelated to Dapr. Explicity applying a Dapr resiliency policy doesn't override these implicit retry policies. Rather, the resiliency policy augments the built-in retry, which can cause repetitive clustering of messages. |
| @@ -12,7 +12,7 @@ no_list: true | |||
| The following table lists publish and subscribe brokers supported by the Dapr pub/sub building block. [Learn how to set up different brokers for Dapr publish and subscribe.]({{< ref setup-pubsub.md >}}) | |||
|
|
|||
| {{% alert title="Pub/sub component retries vs inbound resiliency" color="warning" %}} | |||
| Each pub/sub component has its own built-in retry behaviors. Before explicity applying a [Dapr resiliency policy]({{< ref "policies.md" >}}), make sure you understand the implicit retry policy of the pub/sub component you're using. Instead of overriding these built-in retries, Dapr resiliency augments them, which can cause repetitive clustering of messages. | |||
| Each pub/sub component has its own built-in retry behaviors, unique to their third party and not set by Dapr. Before explicity applying a [Dapr resiliency policy]({{< ref "policies.md" >}}), make sure you understand the implicit retry policy of the pub/sub component you're using. Instead of overriding these built-in retries, Dapr resiliency augments them, which can cause repetitive clustering of messages. | |||
There was a problem hiding this comment.
Suggested change
| Each pub/sub component has its own built-in retry behaviors, unique to their third party and not set by Dapr. Before explicity applying a [Dapr resiliency policy]({{< ref "policies.md" >}}), make sure you understand the implicit retry policy of the pub/sub component you're using. Instead of overriding these built-in retries, Dapr resiliency augments them, which can cause repetitive clustering of messages. | |
| Each pub/sub component has its own built-in retry behaviors, unique to the message broker solution and unrelated to Dapr. Before explicity applying a [Dapr resiliency policy]({{< ref "policies.md" >}}), make sure you understand the implicit retry policy of the pub/sub component you're using. Instead of overriding these built-in retries, Dapr resiliency augments them, which can cause repetitive clustering of messages. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Ask is for examples of built-in retries, but these are set by the third parties themselves, not Dapr. Clarifying this in the note.
Issue reference
PR will close: #4433