[Pub/sub resiliency] clarify built-in retries vs Dapr's retry policies

daprdocs/content/en/operations/resiliency/policies.md

@@ -35,7 +35,13 @@ If you don't specify a timeout value, the policy does not enforce a time and def
 
 ## Retries
 
-With `retries`, you can define a retry strategy for failed operations, including requests failed due to triggering a defined timeout or circuit breaker policy. The following retry options are configurable:
+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.
+{{% /alert %}}
+
+The following retry options are configurable:
 
 | Retry option | Description |
 | ------------ | ----------- |

daprdocs/content/en/reference/components-reference/supported-pubsub/_index.md

@@ -11,6 +11,11 @@ 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.
+{{% /alert %}}
+
+
 {{< partial "components/description.html" >}}
 
 {{< partial "components/pubsub.html" >}}