From 580de08a290dcf078fe6f72154d5af67d2c3f5e5 Mon Sep 17 00:00:00 2001 From: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Date: Wed, 29 Jan 2025 14:54:14 -0500 Subject: [PATCH 1/2] Update daprdocs/content/en/operations/resiliency/policies.md Co-authored-by: Marc Duiker Signed-off-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> --- daprdocs/content/en/operations/resiliency/policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/operations/resiliency/policies.md b/daprdocs/content/en/operations/resiliency/policies.md index e27f6bb8f..59574cc7d 100644 --- a/daprdocs/content/en/operations/resiliency/policies.md +++ b/daprdocs/content/en/operations/resiliency/policies.md @@ -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, 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. {{% /alert %}} The following retry options are configurable: From c61138ab46dbb0dc07545dc8545ac4cd3f32857a Mon Sep 17 00:00:00 2001 From: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Date: Wed, 29 Jan 2025 14:54:23 -0500 Subject: [PATCH 2/2] Update daprdocs/content/en/reference/components-reference/supported-pubsub/_index.md Co-authored-by: Marc Duiker Signed-off-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> --- .../reference/components-reference/supported-pubsub/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/_index.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/_index.md index b47dc5f3a..dbb8c4966 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/_index.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/_index.md @@ -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, 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. {{% /alert %}}