- Newest
- Most votes
- Most comments
The issue was that the messages had difference message group id. When the lambda finished handling the message with one group id, before the visibility timeout, and there was another message with another group id, this new message wasn't handled until the visibility timeout passed.
Different message group ids was not really needed, When I used constant message group id, all messages were handled 1 right after the other, even the visibility timeout didn't pass.
When Lambda reserved concurrency is set to 1, then only one instance of the Lambda function will be invoked. As long as that Lambda function is functioning correctly, it will be the only Lambda function available to process messages. If that is the expected behavior, then only 1 message will be processed at a time from this queue.
When you send the 2 messages, do they have different message deduplication IDs?
Does all the messages have the same Group ID? Lambda will never process messages from the same group ID at the same time.
Are you returning a valid response from the Lambda function? (verify in the logs that there are no errors). If you are not, the Lambda service will not delete the message from the queue, and when the visibility timeout expires, either Lambda will process the message again, or SQS will discard the message or move it to a DLQ, based on configuration (number of retries, DLQ). During the visibility timeout, Lambda will not handle messages with the same group ID.
Relevant content
- Accepted Answerasked 10 months ago
- asked 4 months ago
- asked 2 months ago
AWS OFFICIALUpdated a month ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 6 months ago
They have different message body, and Content-based deduplication is Enabled. It's ok one message is processed at a time, but I expect that once message is done, the next one will start right away, while it start only once the visibility timeout passes. Can it be related to different message group ids for the messages?
Content-based deduplication is for an SNS FIFO topic subscribed by a SQS FIFO queue where SNS uses the message body to generate a unique hash value as the deduplication ID. If this isn't a SNS FIFO topic to SQS FIFO queue then you'll need to set the message deduplication ID yourself.