Home > Back-end >  How does SQS keep track of messages?
How does SQS keep track of messages?

Time:11-23

I have a pretty standard setup of feeding SQS to Lambda. The lambda reads the message and makes a web request to a defined endpoint.

If I encounter an exception during processing of the SQS message that is due to the form of the message then I put the message on a dead letter queue.

If I encounter an error with the web request, I put the message back on the feeding queue to make the HTTP request at a later time.

This seems to work fine, but we just ran into an issue where an HTTP endpoint was down for 4 days and the feeding queue dropped the message. I imagine this has something to do with the retention period setting of the queue.

Questions

  1. Is there a way to know, in the lambda, how many times a message has been replayed?

  2. How did the feeder queue know that the message that was re-enqueued was the same as the one that was originally put on the queue?

  3. I'm currently not explicitly deleting a message off the queue. Not having that, hasn't seemed to cause any issues, no re-processing of messages or anything. Should I be explicitly deleting them?

CodePudding user response:

The normal process would be:

  • The AWS Lambda function is triggered, with the message(s) passed via the event parameter
  • If the Lambda function successfully processes the message(s), it should return a 'success' code (200) and the message is automatically removed from the queue
  • If the Lambda function is unable to process the message, it should return a 'failure' code (eg 400) and Amazon SQS will automatically attempt to re-process the message (unless it has exceeded the retry count)
  • If the Lambda function fails (eg due to a timeout), Amazon SQS will automatically attempt to re-process the message (unless it has exceeded the retry count)
  • If a message has exceeded its retry count, Amazon SQS will move the message to the Dead Letter Queue

To answer your questions:

  1. If you wish to take responsibility for these activities yourself, you can use the ApproximateReceiveCount attribute on the message. In the request, it appears that you should add AttributeNames=['ApproximateReceiveCount'], but the documentation is a bit contradictory. You might need to use All instead.
  2. Since you are sending a new message to the queue, Amazon SQS is not aware that it is the same message. The message is not 're-enqueued' since it is a new message.
  3. When your Lambda function returns 'success' (200), the message is being deleted off the queue for you.

You might consider using the standard functionality for retries and Dead Letter Queues rather than implementing that logic yourself.

  • Related