From b4fb01d0b562a122fe8f9afa4c721d3f4e6eb50b Mon Sep 17 00:00:00 2001 From: Steve Bjorg Date: Wed, 27 Mar 2019 11:58:27 -0700 Subject: [PATCH] Clarify wording on failure for poll-based event sources that are not stream-based The original phrasing "When a message is not successfully processed" seems to indicate that something happens on each failed attempt to process the message, but that is not the case. Something happens after a period of time if all attempts to process have failed or no attempts have been made. In short, when the message has not been processed successfully. Also, it is the failed message that is sent to the Dead-Letter Queue. No information about why it failed is sent. --- doc_source/retries-on-errors.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc_source/retries-on-errors.md b/doc_source/retries-on-errors.md index 3131670c..c53bd1f6 100644 --- a/doc_source/retries-on-errors.md +++ b/doc_source/retries-on-errors.md @@ -15,8 +15,8 @@ Lambda handles retries in the following manner, depending on the source of the i The exception is treated as blocking, and AWS Lambda will not read any new records from the shard until the failed batch of records either expires or is processed successfully\. This ensures that AWS Lambda processes the stream events in order\. + **Poll\-based event sources that are not stream\-based** – This consists of Amazon Simple Queue Service\. If you configure an Amazon SQS queue as an event source, AWS Lambda will poll a batch of records in the queue and invoke your Lambda function\. If the invocation fails or times out, every message in the batch will be returned to the queue, and each will be available for processing once the [Visibility Timeout](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) period expires\. \(Visibility timeouts are a period of time during which Amazon Simple Queue Service prevents other consumers from receiving and processing the message\)\. - Once an invocation successfully processes a batch, each message in that batch will be removed from the queue\. When a message is not successfully processed, it is either discarded or if you have configured an [Amazon SQS Dead Letter Queue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-dead-letter-queue.html), the failure information will be directed there for you to analyze\. + Once an invocation successfully processes a batch, each message in that batch will be removed from the queue\. When a message fails to be processed successfully, it is either discarded by the queue or if you have configured an [Amazon SQS Dead Letter Queue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-dead-letter-queue.html), the failed message will be directed there for you to analyze\. If you don't require ordered processing of events, the advantage of using Amazon SQS queues is that AWS Lambda will continue to process new messages, regardless of a failed invocation of a previous message\. In other words, processing of new messages will not be blocked\. -For more information about invocation modes, see [AWS Lambda Event Source Mapping](intro-invocation-modes.md)\. \ No newline at end of file +For more information about invocation modes, see [AWS Lambda Event Source Mapping](intro-invocation-modes.md)\.