Merge branch 'v1.11' into low-application-helath-probe-timeout

daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md

@@ -100,16 +100,29 @@ Dapr solves multi-tenancy at-scale with [namespaces for consumer groups]({{< ref
 
 ### At-least-once guarantee
 
-Dapr guarantees at-least-once semantics for message delivery. When an application publishes a message to a topic using the pub/sub API, Dapr ensures the message is delivered *at least once* to every subscriber.
+Dapr guarantees at-least-once semantics for message delivery. When an application publishes a message to a topic using the pub/sub API, Dapr ensures the message is delivered *at least once* to every subscriber. 
+
+Even if the message fails to deliver, or your application crashes, Dapr attempts to redeliver the message until successful delivery.
+
+All Dapr pub/sub components support the at-least-once guarantee.
 
 ### Consumer groups and competing consumers pattern
 
-Dapr automatically handles the burden of dealing with concepts like consumer groups and competing consumers pattern. The competing consumers pattern refers to multiple application instances using a single consumer group. When multiple instances of the same application (running same Dapr app ID) subscribe to a topic, Dapr delivers each message to *only one instance of **that** application*. This concept is illustrated in the diagram below.
+Dapr handles the burden of dealing with consumer groups and the competing consumers pattern. In the competing consumers pattern, multiple application instances using a single consumer group compete for the message. Dapr enforces the competing conusmer pattern when replicas use the same `app-id` without explict consumer group overrides. 
+
+When multiple instances of the same application (with same `app-id`) subscribe to a topic, Dapr delivers each message to *only one instance of **that** application*. This concept is illustrated in the diagram below.
 
 <img src="/images/pubsub-overview-pattern-competing-consumers.png" width=1000>
 <br></br>
 
-Similarly, if two different applications (with different app-IDs) subscribe to the same topic, Dapr delivers each message to *only one instance of **each** application*.
+Similarly, if two different applications (with different `app-id`) subscribe to the same topic, Dapr delivers each message to *only one instance of **each** application*.
+
+Not all Dapr pub/sub components support the competing consumer pattern. Currently, the following (non-exhaustive) pub/sub components support this:
+
+- [Apache Kafka]({{< ref setup-apache-kafka >}})
+- [Azure Service Bus Queues]({{< ref setup-azure-servicebus-queues >}})
+- [RabbitMQ]({{< ref setup-rabbitmq >}})
+- [Redis Streams]({{< ref setup-redis-pubsub >}})
 
 ### Scoping topics for added security
 

daprdocs/content/en/developing-applications/building-blocks/pubsub/subscription-methods.md

@@ -223,7 +223,7 @@ Both of the handlers defined above also need to be mapped to configure the `dapr
 app.UseEndpoints(endpoints =>
 {
     endpoints.MapSubscribeHandler();
-}
+});
 ```
 
 {{% /codetab %}}