Please clarify exponential back-off and retry when making requests

[KarlErickson]

Customer feedback that we've received on Tutorial: Read a secret from Azure Key Vault in a Spring Boot application is also applicable to this article. For details, see MicrosoftDocs/azure-dev-docs#863. The relevant details are provided by @moarychan at this response to the original issue.

Thanks!

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: fbc6bfba-ef99-bfbd-23e6-987d570b81d4
• Version Independent ID: c5f7c3c6-ee98-2c29-3a5f-9a82b5bd57c8
• Content: Azure Key Vault throttling guidance
• Content Source: articles/key-vault/general/overview-throttling.md
• Service: key-vault
• Sub-service: general
• GitHub Login: @msmbaldwin
• Microsoft Alias: mbaldwin

[RamanathanChinnappan-MSFT]

@KarlErickson

Thanks for your feedback! We will investigate and update as appropriate.

[YashikaTyagii]

@KarlErickson Thanks for your feedback! We have assigned the issue to author who will provide further updates.

[jlichwa]

Hello @KarlErickson I don't understand your request. From discussions I see this: "There's a default retry strategy ExponentialBackoff under azure-core for each HTTP-based client, in which the max retries is 3, the base delay is 800 milliseconds, the max delay is 5 seconds."

Are you suggesting that above should be used instead? The defaults above does not follow our guidelines for our service which is min 2 seconds and max 16 seconds with 5 retries.

[KarlErickson]

@moarychan can you reply? Thanks!

[moarychan]

This is a default behavior for the Azure SDK level, @KarlErickson could you help involve the SDK team member to explain more details?

I have updated the MS reference doc for the Spring Cloud Azure configuration part, added configuration examples, we will keep adding more common scenarios.

[jlichwa]

@moarychan we understand if it is default behavior but it is not how our service behave today. Key Vault throttling is using 10 seconds blocks, so that is why our service requires extended exponential back-off which we had described in our guidelines.

I'm dev experience PM for Key Vault driving SDK team the code snippet is coming from our SDK team.

[moarychan]

Thanks @jlichwa Sorry, I'm not too familiar with the behavior of the service, but any code snippets are welcome, could you please add more descriptions in this article recommends exponential back-off and retry to make the doc clear for customers?

[jlichwa]

@moarychan in general our recommendations are: Recommended client-side throttling method On HTTP error code 429, begin throttling your client using an exponential backoff approach:

    Wait 1 second, retry request
    If still throttled wait 2 seconds, retry request
    If still throttled wait 4 seconds, retry request
    If still throttled wait 8 seconds, retry request
    If still throttled wait 16 seconds, retry request

We provided example in .NET, but any code which would do above is fine. Do you have any suggestions how we can make it better?

[moarychan]

Thanks @jlichwa .

@KarlErickson , the original issue is raised for the unclear documentation of Key Vault, I check the previous comment from Ed Burns, should we wait for Manfred to give a more detailed description on the doc recommends exponential back-off and retry?

[KarlErickson]

@mnriem can you provide any additional guidance here? Thanks!

[mnriem]

@KarlErickson Please coordinate with the Azure Spring team on this as this functionality was delivered by them

[jlichwa]

If there any asks to provide better explanation on requirements with 2,4,8,16 seconds. Please let us know. Thank you #please-close