Service Bus Queue Trigger Retry Policy Not Working as expected

[raiajithkumarr]

Hi Team, We are trying to retry 3 times on SB Queue failure . Here I followed as per this document : microsoft document

"extensions": { "serviceBus": { "clientRetryOptions":{ "mode": "exponential", "tryTimeout": "00:01:00", "delay": "00:00:00.80", "maxDelay": "00:01:00", "maxRetries": 3 },

        "autoCompleteMessages": true
    
    }
}

I Configured in host.json file But still it is not working. --Please provide suggestion here

Where as if we configured like this it is working : [ExponentialBackoffRetry(5, "00:00:04", "00:01:00")] here problem is these values need to be configured at compile time means it can not be taken from config and want to know at what retry number it succeed for both configuration -- Please provide suggestion here

For example I configured in azure portal queue deliver count : 2 Max Retry count =3 Now at first deliver count : 1 and it succeeded at 3 retry now total count is 4 (default try + configured retry count) Now at second deliver count : 2 and it succeeded at 2 retry now total count is 3 Now total run to success processing is : first deliver count + first total retry is (3) +second delivery count+second retry current count (2) =7 (for above iteration)

Microsoft.Azure.WebJobs.Extensions.ServiceBus 5.8.1 version we are using.

What to know at what iteration it succeeded.

For example I configured in azure portal queue deliver count : 2 Max Retry count =3 Now at first deliver count : 1 and it succeeded at 3 retry now total count is 4 Now at second deliver count : 2 and it succeeded at 2 retry now total count is 3 Now total run to success processing is : first deliver count + first total retry is (3) +second delivery count+second retry current count (2) =7 (for above iteration)

PFB Sample application

sampleapp.zip

[jsquire]

Hi @raiajithkumarr. Thank you for reaching out and we regret that you're experiencing difficulties. What you're describing is expected behavior. The host configuration and attribute control retries for different contexts and are not equivalent.

The retry values that you're setting in host.json govern the behavior of the Service Bus client library used by the trigger. These retries take place implicitly and transparently when a service operation fails. Unless all retries were unsuccessful, your Function code is unaware that retries took place. Failures in your Function code are not governed by this policy. These retries very rarely increment the delivery count as the operation to read the message itself failed - the message was never delivered and never abandoned.

The ExponentialBackoffRetry attribute applies a retry policy to your Function code, instructing the Functions runtime to retry invocations of your Function if an exception is surfaced. In this scenario, you'll generally see the delivery count increase as the message has been delivered to your code and the exception has caused it to be abandoned.

I'm going to mark this as addressed, but please feel free to unresolve if you'd like to continue the discussion.

[ghost]

Hi @raiajithkumarr. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[raiajithkumarr]

Hi @jsquire Thank you for your response As I mentioned above is there any possibility to pass dynamic arguments or parameters for this attribute ExponentialBackoffRetry

/unresolve

[jsquire]

As I mentioned above is there any possibility to pass dynamic arguments or parameters for this attribute ExponentialBackoffRetry

To my knowledge, there is not; attributes in .NET must be bound to constant values. The docs do not mention that binding expressions are supported. You may want to test that to be sure, or open an issue for the Functions host team, who would be able to answer that authoritatively.

[ghost]

Hi @raiajithkumarr. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[raiajithkumarr]

We will added business logic to retry based on configuration