You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: msal-dotnet-articles/advanced/exceptions/retry-policy.md
+7-119Lines changed: 7 additions & 119 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,129 +3,17 @@ title: Retry policies
3
3
description: Learn how to implement a custom retry policy for token acquisition operations in .NET with MSAL. Increase your service availability with our detailed guide.
4
4
---
5
5
6
-
# Retry policies
6
+
# Retry Policies are baked in the libary
7
7
8
-
This document explains how to implement a custom retry policy around token acquisition operations. For other tips on how to increase the availability of your service, see [High Availability](../high-availability.md).
8
+
MSAL has its own retry policies. In rare cases you can choose to disable the internal retry policies and add your own. See [HttpClient tips](../httpclient.md).
9
9
10
-
##Better HTTP stack
10
+
### MSAL implements a simple "retry-once" for errors with HTTP error codes 5xx
11
11
12
-
The default HTTP stack in .NET is not great. See [HttpClient tips](../httpclient.md) for details.
12
+
MSAL.NET implements a simple retry-once with 1 second delay mechanism for errors with HTTP error codes 500-600, for the token endpoint.
13
+
For managed identity, the retry follows the guidelines of each source.
13
14
14
-
## MSAL implements a simple "retry-once" for errors with HTTP error codes 5xx
15
+
## Customize the HTTP stack
15
16
16
-
MSAL.NET implements a simple retry-once mechanism for errors with HTTP error codes 500-600. For more control / availability, consider disabling the default retry policy and define your own.
17
+
In some cases, such as using proxies, you might want to customize the Http Stack. See [HttpClient tips](../httpclient.md) for details.
17
18
18
-
Note that Microsoft Entra ID may return a Retry-After header indicating to clients to pause for a few seconds, which needs to be taken into account.
The example above shows how to introduce a retry policy at MSAL level, since MSAL transforms HTTP errors 5xx into MSAL specific exceptions.
117
-
It is also possible, to use an HTTP level retry policy, which can be introduced directly via the HttpClient.
118
-
119
-
Both possibilities are valid, with a slight preference for library-level retry policy. The reason for this is that we are trying to classify more exceptions as retry-able, for example Microsoft Entra error AADSTS50087 (see [Microsoft Entra error codes](/azure/active-directory/develop/reference-aadsts-error-codes#aadsts-error-codes) for full list). Tracking [work item](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/3649).
120
-
121
-
## Fallback instead of retry
122
-
123
-
Internally, Microsoft Entra ID uses several fallback mechanisms which help applications retrieve tokens even when Microsoft Entra ID is struggling. Regional token issuers (ESTS-R) automatically fallback to the global issuer if they go down. An emergency token issuer, which does not depend on Azure infrastructure, takes over if Microsoft Entra goes down.
124
-
125
-
Client applications do not need to do anything to benefit from these measures.
126
-
127
-
## What is the Retry-After header?
128
-
129
-
When the Security Token Service (STS) is too busy or having problems, it returns an HTTP error [429](https://developer.mozilla.org/docs/Web/HTTP/Status/429). It may also return other HTTP error codes, such as 503. Alongside the response it will add a [Retry-After header](https://developer.mozilla.org/docs/Web/HTTP/Headers/Retry-After), which indicates that the client should wait before calling again. The wait delay is in seconds, as per spec.
130
-
131
-
`MsalServiceException` surfaces `System.Net.Http.Headers.HttpResponseHeaders` as a property named `Headers`. You can therefore leverage additional information to the Error code to improve the reliability of your applications. In the case we just described, you can use the `RetryAfter` property (of type `RetryConditionHeaderValue`) and compute when to retry.
0 commit comments