4

Is there a config setting somewhere where one can have lambda or SQS add a reason attribute when a message is sent to the DLQ?

A message can end up in a dead letter queue either by error or by throttling. In the case of a message being throttled, there isn't anything necessarily wrong with it, and it can be sent back into the main queue to be processed again. But a message that can't be processed at all, say, due to bad formatting or bad data, cannot be sent back to main queue because it will just fail again.

DLQ Redrive back to source will repost the throttled messages (which in most cases will succeed,) but it will also reposts everything else, which I know will fail.

But there is no mechanism I can find which tags the messages depending on what path they took to arrive at the DLQ.

What I had wanted to do was iterate the DLQ and pick up messages that were throttled and put them back in the main queue, and the others save in a db.

Anyone have any ideas?

Kenobi
  • 465
  • 6
  • 13

1 Answers1

0

I believe you will need to implement this logic yourself within the application as there is currently no way to automatically add message attributes. Below is one way you could implement it:

  • Within the application, inspect the error. If the error can be retried, put the message back on the original queue. Or let the visibility timeout expire so the message gets automatically added back to the queue. You can set a redrive threshold to limit the number of retries before sending to a DLQ.
  • If the error is not retriable, add it to a failure queue where you can inspect the message later for debugging.

With this solution, you would get automatic retries. And you could monitor both the DLQ and the failure queue to be notified of both failure cases.

John Veldboom
  • 2,049
  • 26
  • 29