3

I'm using version 5.2.0 of the Microsoft.Azure.WebJobs.Extensions.ServiceBus package in my Azure Function. According to the docs here the new version supports automatic retry on failed operations. This is my host.json:

{
  "version": "2.0",
  "extensions": {
    "serviceBus": {
      "clientRetryOptions": {
        "mode": "Exponential",
        "tryTimeout": "00:02:00",
        "delay": "00:00:02.00",
        "maxDelay": "00:30:00",
        "maxRetries": 10
      }
    }
  }
}

Which - apart from the time values - is exactly the same as in the docs. In my Function that is triggered by a ServiceBusTrigger I throw an exception under certain circumstances. I want the message to be delayed, as is described in the documentation. But it is put back at the head of the queue and retried immediately, with no delay. I've spent 2 working days on this, and the mish-mash of versions, incorrect documentation, and examples I've found online, I've tried all manner of permutations, but I just cannot get this to work.

I just can't see the wood for the trees, any longer. Can anyone see what I'm doing wrong?

Andrew Plank
  • 942
  • 10
  • 22

3 Answers3

1

The options that you're configuring govern the implicit retry behavior of the Service Bus clients used by the Function bindings. When reading or publishing a message fails due to an error that is deemed transient, these settings are applied to client retries. This flow is invisible to your Function, other than being observable by read/publish taking longer to complete than normal.

Exceptions in your Function code are not governed by these settings. These types of exceptions are governed by the Functions error handling and retries configuration.

Jesse Squire
  • 6,107
  • 1
  • 27
  • 30
0

Seems this question was asked and answered here. Seems that retry only applies to certain errors, namely transient, that it deems is retriable.

Matt M
  • 1,093
  • 2
  • 11
  • 26
  • Yeah I saw that one, but it relates to the older version of Microsoft.Azure.WebJobs.Extensions.ServiceBus. As far as I can tell, the `clientRetryOptions` in v5+ were implemented to address this shortcoming. – Andrew Plank Mar 04 '22 at 15:07
  • Also, neither this nor the other answer is clear to me. Can RetryOptions be used, or not? Lets say we have a C# Console application that creates a `ServiceBusClient` with `ServiceBusRetryOptions` set... it does not seem to work and timeouts are super long (20 minutes or so) – Ted Aug 09 '23 at 11:19
0

Like already mentioned in the other answers, these retry options only apply to internal (transient) exceptions. What you need can be achieved by the new retry policies (preview):

[FunctionName("EventHubTrigger")]
[ExponentialBackoffRetry(5, "00:00:04", "00:15:00")]
public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log)
{
// ...
}

Alternatively, specifically for ServiceBus you can achieve a similar behavior by disabling auto-complete and leveraging the lock duration property on the queue. The number of retries can be controlled by using the max delivery count.

Edit: For ServiceBus, these retries are going to be removed soon.

Alex AIT
  • 17,361
  • 3
  • 36
  • 73
  • Warning pops up when using this: `Soon retries will not be supported for function 'FunctionName'. For more information, please visit http://aka.ms/func-retry-policies.` – CularBytes Jul 15 '22 at 13:05
  • @CularBytes Correct, ServiceBus retries will be removed. EventHub retries will continue to be available, as stated in the linked message. – Alex AIT Jul 15 '22 at 13:57