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

[chlowell]

MSAL must observe Context cancellation while waiting to retry. See for example the Azure SDK retry policy

[chlowell]

You probably need to rewind the request body before retrying (this will matter for Cloud Shell). Make sure you have a test verifying retries have the same content as the initial attempt

[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.

[chlowell]

This should consider the Source. retryStatusCodes follows IMDS docs, and that guidance doesn't make sense for other APIs. For example, in general you don't want to retry 404. Azure SDK retries these codes by default and special-cases IMDS

[bgavrilMS]

CC @neha-bhargava as this is probably a small bug in all other MSALs (which should not affect Azure SDK)

[4gust]

After discussions with @bgavrilMS, we have decided to maintain consistency with other MSAL implementations. We will create a bug report to address this issue and ensure that the necessary updates are applied across all relevant areas.

[sonarcloud]

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 SonarCloud