How does Service Bus handle message retries and dead-lettering

Azure Service Bus handles message retries and dead-lettering using a combination of 'retry policies', 'message lock durations', and 'dead-letter queues (DLQs)'. Here’s how it works, particularly in the context of 'transient' vs. 'non-transient failures':

'Message Retries and Transient Failures'

• 'Transient failures' (e.g., network glitches, throttling, temporary unavailability) are expected to resolve on their own.
• Azure Service Bus uses a 'retry policy' at the client SDK level (e.g., ServiceBusClientOptions.RetryOptions) to automatically retry these operations.
• Retry behavior is configurable (e.g., max retries, backoff strategy), and applies to operations like sending, receiving, or completing messages.
• While retrying, the message remains 'locked' (not visible to others) for the duration of the 'lock timeout' (default 30 seconds, configurable).
• If the message isn’t completed or deferred within this lock period, it becomes 'unlocked and available' to other receivers, counting as a 'delivery attempt'.

'Non-Transient Failures and Dead-Lettering'

• 'Non-transient failures' (e.g., business rule violations, corrupted data) typically don’t succeed even with retries.
• After a message exceeds the configured 'MaxDeliveryCount' (default is 10), it is 'automatically dead-lettered'.
• The message is moved to the 'Dead-Letter Queue (DLQ)' associated with the queue or subscription.
• Each dead-lettered message includes properties explaining the dead-letter reason (DeadLetterReason, DeadLetterErrorDescription).

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin