Implemented Retry Policy

[4gust]

Pull Request: Implement Retry Policy for Client

Overview

This pull request introduces a retry policy for network calls in the client. The retry policy aims to enhance the resilience of our application by allowing it to automatically retry failed requests up to a maximum of three times.

Changes Made

• Retry Policy Implementation:

  • A retry mechanism has been added to handle transient errors in network calls.
  • The default maximum retry count is set to 3.

• Configuration Option to Disable Retry Policy:

  • Introduced an optional method WithRetryPolicyDisabled() for the client.
  • When this method is used, the maximum retry count is reduced to 1 (effectively disabling the retry mechanism).

Default Behavior (Retries Enabled)

By default, the client will automatically retry failed requests up to 3 times with delay of 1 second. Here’s how to create the client with the retry policy enabled:

client, err := mi.New(SystemAssigned())
if err != nil {
    // Handle error
}

Default Behavior (Retries Disabled)

By default, the client will not retry the failed request. Here’s how to create the client with the retry policy disabled:

client, err := mi.New(SystemAssigned(), WithRetryPolicyDisabled())
if err != nil {
    // Handle error
}

Error List when retry is done.

	http.StatusNotFound,                      // 404
	http.StatusGone,                          // 410
	http.StatusTooManyRequests,               // 429 // retry after.
	http.StatusInternalServerError,           // 500
	http.StatusNotImplemented,                // 501
	http.StatusBadGateway,                    // 502
	http.StatusServiceUnavailable,            // 503
	http.StatusGatewayTimeout,                // 504
	http.StatusHTTPVersionNotSupported,       // 505
	http.StatusVariantAlsoNegotiates,         // 506
	http.StatusInsufficientStorage,           // 507
	http.StatusLoopDetected,                  // 508
	http.StatusNotExtended,                   // 510
	http.StatusNetworkAuthenticationRequired, // 511

[chlowell]

Is there a spec for this feature? It seems very basic e.g. no backoff, hardcoded retry count and delay. Blockers are

• implicit upgrade to Go 1.21
• cancellation
• rewinding request bodies

[4gust]

It is very basic retry, and has a fix 1 second between retry and max count of 3 retries
This is what we set for Private preview.

[bgavrilMS]

Is there a spec for this feature? It seems very basic e.g. no backoff, hardcoded retry count and delay. Blockers are

• implicit upgrade to Go 1.21
• cancellation
• rewinding request bodies

This is the retry policy that was discussed with MSI team and implemented in all MSALs. If you feel that this is wrong, let's pls open bugs on all MSALs. But it is important for MSALs to be consistent here.

Note that MSALs do not offer a DefaultAzureCredential chaining, so the usage scenario is different. Azure SDK can and should disable the retry policy so as to introduce your own.

[chlowell]

I'm sorry, I still don't know which status codes this policy is supposed to retry on. Right now, its retriable codes are reasonable in general cases but incorrect for IMDS. Do you intend it to apply IMDS retry guidance to all services?

[sonarqubecloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud