Skip to content

Clarify wording on failure for poll-based event sources that are not stream-based #114

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 19, 2019
Merged

Clarify wording on failure for poll-based event sources that are not stream-based #114

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions doc_source/retries-on-errors.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)\.
For more information about invocation modes, see [AWS Lambda Event Source Mapping](intro-invocation-modes.md)\.