[Host.AmazonSQS] A way to dead letter early for an SQS consumer

[tjpeel-ee]

As per the approach for the Azure service bus error handler, we can dead letter early by returning a dead letter result.

Is the same possible for SQS consumers in some way as from what I can determine from the code it's not?

I would need to wait until the delivery count has been met before AWS determines it's a dead letter I presume.

Thanks

[zarusz]

In SQS It's currently not supported to fail faster before the retry count is reached. We can add that along the same lines that ASB transport does it. Happy to accept a PR. I have several things on my immediate list including release of SNS to stable build first.

[zarusz]

Thanks for the feature request - I'm currently looking into adding Dead Letter Queue (DLQ) support for SQS in SlimMessageBus.

This change would require introducing DLQ support directly into the .Consume() declarations. One key question is around the default behavior: Should DLQs be opt-in, only enabled when explicitly configured with a .DeadLetterQueue() call? Or should we enable DLQs by default, using a sensible naming convention like {queue-name}_dlq, and allow users to opt out if needed?

I'm currently leaning toward enabling DLQ support by default. This approach provides out-of-the-box reliability for all consumers, while still giving developers the flexibility to override or disable DLQ behavior as needed.

Example:

mbb.Consume<MyMessage>(x => {
    x.Queue("my-queue");
    
    // DLQ is automatically set to "my-queue_dlq" by default.

    x.DeadLetterQueue("dlq-my-queue"); // Custom DLQ name
    x.DeadLetterQueue(null);           // Explicitly disable DLQ
});

I’d love to hear your thoughts - do you agree with enabling DLQ by default and allowing opt-out, or would you prefer an opt-in model?

Looking forward to your feedback!

Also: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html

[tjpeel-ee]

Dead lettering is a common pattern but it depends how much convention you want to add to SMB that will ultimately dictate how dead lettering is performed.

Out of the box, I would expect consumption to dead letter after X amount of unsuccessful consumption attempts, all of which is provided by the bus itself and not anything SMB is doing specifically.

Where SMB would help is, like the case of the Azure implementation, allow a consumption to dead letter sooner if there is an error that will never resolve regardless of the number of consumption attempts.

The names of dead letter queues should be irrelevant if you let the bus drive the behaviour.

Your example of specifying the dead letter queue name, or implying it via convention, would be, for our use case, additional config we would then need to manage. But this might be OK in the scope of SMB and what you want it to do, I can't speak for that direction as I don't know enough about the library outside of what I have observed.

[svs-rh]

As a user I personally would prefer off by default. But whatever you decide, please consider this use case:

SQS queues have native deadlettering settings, which are invisible to the client. And some users may want to completely rely on that - we want our application to not have any client-side deadlettering logic and just let the messages fall-through to be handled by queue's deadlettering settings. Remains to see if this is a good idea overall, but while investigating different messaging frameworks, I have encountered that this use case is actually not always supported, because default DLX settings interfere.