I have a use case to know how many times sqs message has been read in my code.

For example we read message from SQS, for abc reason/exception we cant process that message . Now the same message available in queue to read after visibility timeout.

This will create endless loop. Is there a way to know how many times particular sqs message has been read and returned back to queue.

I am aware this can be handled via dead letter queue. Since that requires more effort I am checking is there any other option

i dont want to retry the message if it fails more than x time and i want to delete it. Is it possible in SQS

CodePudding user response：

When calling ReceiveMessage(), you can specify a list of AttributeNames that you would like returned.

One of these attributes is ApproximateReceiveCount, which returns "the number of times a message has been received across all queues but not deleted".

It is an 'approximate' count due to the highly parallel nature of SQS -- it is possible that the count is slightly off if a message was processed around the same time as this request.

CodePudding user response：

You can do this manually by looking at the approximateReceiveCount attribute of your messages, see this question on how to do so. You just need to implement the logic to read the count and decide whether to try processing the message or delete it. Note however that receiveCount is affected by more than just programmatically processing messages: viewing messages in the console will increment it too.

That being said a DLQ is a premade solution for exactly this usecase. It's not a lot of additional work: all you have to do is create another SQS queue, set it as the DLQ of your processing queue, and set the number of retries. Then, the DLQ handles all your redrive logic, and instead of deleting messages after n failures they're moved to the DLQ, where you can manually look at them to understand why they're failing, set metrics alarms on the queue, and if you want manually re-drive the messages into your processing queue. Or just ignore them until they age out of the queue based on its retention policy - the important thing is that the DLQ gives you the option of being able to see which messages failed after the fact, while deleting them outright does not.