How does ExponentialBackoffRetry works with ServiceBus Trigger for Azure function?

Question

I want to implement a very simple behavior in my Azure Function: if there is an exception during handling, I want to postpone the next retry for some time. As far as I know there is no direct possibility for that in the Service Bus e.g. (unless one creates a new message), but Service Bus Trigger has a possibility for ExponentialBackoffRetry.

I have not found any documentation on how that might work with regards to Service Bus Connection. I.e. what happens with the message after the execution of the function fails.

One possible way is to keep the message in functions infrastructure and keep renewing the lock for the duration I suppose. Some more practical questions on what I am wondering about:

1. How long can I use backoff retry (e.g. if I want retry to up to 7 days e.g. will that work?)
2. What happens when host is being reset/restarted/scaled, do I lose this backoff due to implementation details or it is still somehow maintained?

Answer 1

From the documentation:

Using retry support on top of trigger resilience

The function app retry policy is independent of any retries or resiliency that the trigger provides. The function retry policy will only layer on top of a trigger resilient retry. For example, if using Azure Service Bus, by default queues have a message delivery count of 10. The default delivery count means after 10 attempted deliveries of a queue message, Service Bus will dead-letter the message. You can define a retry policy for a function that has a Service Bus trigger, but the retries will layer on top of the Service Bus delivery attempts.

For instance, if you used the default Service Bus delivery count of 10, and defined a function retry policy of 5. The message would first dequeue, incrementing the service bus delivery account to 1. If every execution failed, after five attempts to trigger the same message, that message would be marked as abandoned. Service Bus would immediately requeue the message, it would trigger the function and increment the delivery count to 2. Finally, after 50 eventual attempts (10 service bus deliveries * five function retries per delivery), the message would be abandoned and trigger a dead-letter on service bus.

For the exponential retries, you likely need to keep the total backoff time + processing to less than what a function can hold on to the message or else the lock will expire, and even successful processing will result in an exception and retry.

The way Service Bus locks messages today, exponential backoff on top of Azure Service Bus is not a great idea. Once durable terminus is possible (unlimited lock time w/o the need to renew), this will make much more sense.

Update: Functions retry feature is being deprecated.