ServiceBus won't deadletter messages when processing raises generic exceptions

[bruno-brant]

Liquid will deadletter the message only when:

• The method returns a Task
• ReceiveModeisPeekLock (deleteAfterRead = false`).
• The exception thrown has a Inner Exception (a first level exception won't do).
• The inner exception is InvalidInputException or a BusinessValidationException

as can be seen below:

https://github.com/Avanade/Liquid-Application-Framework/blob/00dd8d3af8dc5437ffd6f8a94e95be3c94193efa/src/Liquid.OnAzure/MessageBuses/ServiceBus.cs#L272-L299

This means that on most cases, the message isn't deadlettered. I still need to investigate the default behavior of Service Bus in this case.

[bruno-brant]

So, as can be confirmed on docs,

Queues and subscriptions each have a QueueDescription.MaxDeliveryCount and SubscriptionDescription.MaxDeliveryCount property respectively; the default value is 10. Whenever a message has been delivered under a lock (ReceiveMode.PeekLock), but has been either explicitly abandoned or the lock has expired, the message BrokeredMessage.DeliveryCount is incremented. When DeliveryCount exceeds MaxDeliveryCount, the message is moved to the DLQ, specifying the MaxDeliveryCountExceeded reason code

So, as expected, the Service Bus will dead letter a message automatically after a few (10, by default) attempts. Therefore, it seems that the reasoning behind the current implementation in Liquid is that, if the error is a InvalidInputException or a BusinessValidationException, then we know that the message won't ever be accepted and should be dead-lettered directly.

Other cases will result in retries until a certain number of attempts.