What is the correct way of implementing exponential backoff for the service bus triggered azure function?
For example, the function picks up a message from the service bus, and during execution, it fails due to some temporary problems. It means that this message should be reprocessed later with delay. Service bus support "maximum delivery count", but we can't use it because the message will be reprocessed immediately.
After long research, I found that a lot of people are also faced with that problem, and I collected potential solutions, but all of them have disadvantages:
Azure Durable function. Seems can solve the problem, but it overcomplicates function.
Send a scheduled message to the service bus again and complete the current one. Also complex because should be replicated in each function.
ExponentialBackoffRetry attribute, but seems it's no longer supported for service bus triggered azure function
Call renew from the azure function for the message. ServiceBusMessageActions support only Defer, DeadLetter, Complete
Thread sleep inside azure function plus maxAutoRenewDuration. Easy solution, but it will block handling other messages.
What is the correct way of implementing exponential backoff for the service bus triggered azure function? For example, the function picks up a message from the service bus, and during execution, it fails due to some temporary problems. It means that this message should be reprocessed later with delay. Service bus support "maximum delivery count", but we can't use it because the message will be reprocessed immediately. After long research, I found that a lot of people are also faced with that problem, and I collected potential solutions, but all of them have disadvantages:
A similar question was raised in the next ticket: https://github.com/MicrosoftDocs/azure-docs/issues/90225