SNS/SQS contention

Signed-off-by: Amit Mor <[email protected]>
Signed-off-by: Amit Mor <[email protected]>

daprdocs/content/en/reference/components-reference/supported-pubsub/setup-aws-snssqs.md

@@ -133,6 +133,9 @@ When configuring the PubSub component with SQS dead-letter queues, the metadata
 When running the Dapr sidecar (`daprd`) with your application on EKS (AWS Kubernetes) node/pod already attached to an IAM policy defining access to AWS resources, you **must not** provide AWS access-key, secret-key, and tokens in the definition of the component spec.  
 {{% /alert %}}
 
+#### SNS/SQS Contention with Dapr
+
+Fundamentally, SNS aggregates messages from multiple publisher topics into a single SQS queue by creating SQS subscriptions to those topics. As a subscriber, the SNS/SQS PubSub component consumes messages from that sole SQS queue. However, like any SQS consumer, the component cannot selectively retrieve only messages published to specific SNS topics it is configured to subscribe to. This can result in the component receiving messages originating from topics without associated handlers. Typically this occurs during component initialization, if infrastructure subscriptions are ready before component subscription handlers, or during shutdown, if component handlers are removed before infrastructure subscriptions. Since this issue affects any SQS consumer of multiple SNS topics, the component cannot prevent consuming messages from topics lacking handlers. When this happens, the component logs an error indicating such messages were erroneously retrieved.
 
 ## Create an SNS/SQS instance