fix: use Azure Blob Storage SDK RetryPolicy only to ensure exponential backoff retries
Type of change
-
Bug Fix -
Feature
Does this introduce a change in the core logic?
-
No -
Yes
Does this introduce a change in the cloud provider implementation, if so which cloud?
-
AWS -
Azure -
GCP -
IBM
Updates description?
Currently both SDAPI’s retry mechanism (10 retry attempts) and SDK’s default RetryPolicy (3 retry attempts) were intermingled and that resulted in not an exponential backoff retry. This PR is using only SDK’s RetryPolicy for exponential backoff retry, and it has been configured with the same defaults as before (initial delay is 0.5 seconds, max delay is 32 seconds) except for MaxRetry which is now using 30 retry attempts just to replicate the existing behavior (10 * 3 = 30).
Also if token expires during the call to SDK’s BlobClient, SDK will not refresh token automatically ( as SDAPI/SDMS is not using SDK’s mechanism for token authentication and refresh ) and so it has been extracted as refreshTokenRetry to handle that scenario. This probably can happen only if the call has been retrying for quite some time because the expiry of token has been checked before the call was made and there is a margin of 5 mins before expiry.