Testez les nouvelles tentatives et les délais d’expiration dans les applications .NET qui utilisent Microsoft.Extensions.Http.Resilience

Tip

Vous découvrez la limitation du débit ? Découvrez ce qu’est la limitation du débit et comment la gérer.

En un clin d’œil
Objectif : Vérifiez que votre gestionnaire de résilience HTTP pour .NET réessaye, applique un délai croissant et déclenche un délai d’expiration comme prévu
Heure : 15 minutes
Plugins :GenericRandomErrorPlugin, RetryAfterPlugin, LatencyPlugin
Prérequis :Configurer le proxy de développement, une application .NET qui utilise Microsoft.Extensions.Http.Resilience

Vous avez ajouté AddStandardResilienceHandler() à votre HttpClient. Comment savez-vous que cela fonctionne ? Les API que vous appelez échouent rarement à la demande, et les tests unitaires qui simulent HttpMessageHandler contournent le pipeline de résilience que vous souhaitez tester.

Le proxy de développement se trouve entre votre application et l’API. Elle retourne des erreurs et des réponses lentes à votre application, de sorte que votre application continue de fonctionner sans modification et le gestionnaire de résilience réagit aux réponses HTTP réelles. Vous voyez chaque tentative dans la sortie de Dev Proxy.

Ce que fait le gestionnaire de résilience standard

Avant de tester, sachez à quoi vous attendre. Avec les options par défaut, AddStandardResilienceHandler():

Behavior Default
Nouvelle tentative sur HTTP 500 et plus, 408, 429, HttpRequestException et TimeoutRejectedException
Nombre de tentatives 3, avec temporisation exponentielle et gigue, en commençant à 2 secondes
En-tête Retry-After Honoré. Le gestionnaire attend la durée indiquée par l’API.
Délai d’expiration de la tentative 10 secondes par tentative
Délai d’expiration total 30 secondes pour la requête, y compris toutes les nouvelles tentatives

Pour obtenir la liste complète des stratégies et de leurs valeurs par défaut, consultez Valeurs par défaut de Standard resilience handler.

Acheminer votre application via Dev Proxy

.NET utilise le proxy système. Par conséquent, lorsque vous démarrez Dev Proxy, il intercepte les requêtes de votre application sans modification du code. Pour plus d’informations, consultez Utiliser le proxy de développement avec des applications .NET.

Simuler des erreurs transitoires

Créez une configuration de proxy de développement qui fait échouer les requêtes vers votre API avec les erreurs pour lesquelles le gestionnaire effectue des tentatives. Cet exemple utilise https://api.contoso.com. Remplacez-le par l’URL de l’API que votre application appelle.

Fichier : devproxyrc.json

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "RetryAfterPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll"
    },
    {
      "name": "GenericRandomErrorPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "transientErrors"
    }
  ],
  "urlsToWatch": [
    "https://api.contoso.com/*"
  ],
  "transientErrors": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/genericrandomerrorplugin.schema.json",
    "errorsFile": "transient-errors.json",
    "rate": 50
  }
}

Caution

Ajoutez le RetryAfterPlugin avant le GenericRandomErrorPlugin dans votre fichier de configuration. Si vous l’ajoutez après, GenericRandomErrorPlugin échoue à la requête avant que RetryAfterPlugin puisse la vérifier.

Dans le fichier d’erreurs, définissez une réponse de limitation et deux erreurs de serveur. La valeur @dynamic définit l’en-tête Retry-After et indique au RetryAfterPlugin de vérifier que votre application attend ce délai avant de rappeler l’API.

Fichier : transient-errors.json

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/genericrandomerrorplugin.errorsfile.schema.json",
  "errors": [
    {
      "request": {
        "url": "https://api.contoso.com/*"
      },
      "responses": [
        {
          "statusCode": 429,
          "headers": [
            {
              "name": "Retry-After",
              "value": "@dynamic"
            }
          ]
        },
        {
          "statusCode": 500
        },
        {
          "statusCode": 503
        }
      ]
    }
  ]
}

Démarrez le proxy de développement et exécutez votre application.

devproxy --config-file devproxyrc.json

Avec un taux d’échec de 50 %, la plupart des requêtes aboutissent après une ou deux nouvelles tentatives. Dans la sortie de Dev Proxy, vérifiez que :

  • Après une réponse 429, la tentative suivante vers la même URL se produit après le délai indiqué par Retry-After. Dev Proxy utilise 5 secondes par défaut. Si votre application appelle l’API trop tôt, RetryAfterPlugin le signale et limite la requête.
  • Votre application n’envoie pas plus de nouvelles tentatives que vous avez configurées.
  • Les demandes que vous ne souhaitez pas réessayer, comme une requête POST qui crée un enregistrement, ne sont envoyées qu’une seule fois. Pour les exclure, appelez options.Retry.DisableForUnsafeHttpMethods() ou options.Retry.DisableFor(...).

Tester ce qui se passe lorsque les tentatives sont épuisées

Les nouvelles tentatives masquent les échecs temporaires. Vous devez également savoir ce que fait votre application quand l’API continue d’échouer. Démarrez le proxy de développement avec un taux d’échec de 100% :

devproxy --config-file devproxyrc.json --failure-rate 100

Dev Proxy affiche 4 tentatives pour chaque requête : la requête d’origine et 3 nouvelles tentatives. Après la dernière tentative de nouvelle exécution, le gestionnaire standard ne lève pas. Elle renvoie à votre code la dernière réponse d’erreur. Vérifiez ce que fait votre application avec cela. Par exemple, EnsureSuccessStatusCode() lève un HttpRequestExceptionet GetStringAsync() lève également. Assurez-vous que votre application affiche un message utile ou utilise une solution de repli, au lieu de se bloquer ou d’afficher une erreur générique.

Délais d’expiration des tests

Les API lentes déclenchent un chemin différent dans le gestionnaire. Pour le tester, utilisez LatencyPlugin pour retarder les réponses au-delà du délai d’expiration de la tentative de 10 secondes.

Fichier : devproxyrc.json

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "LatencyPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "slowApi"
    }
  ],
  "urlsToWatch": [
    "https://api.contoso.com/*"
  ],
  "slowApi": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/latencyplugin.schema.json",
    "minMs": 11000,
    "maxMs": 15000
  }
}

Démarrez le proxy de développement et exécutez votre application. Chaque tentative prend plus de 10 secondes. Par conséquent, le délai d’expiration de la tentative l’annule et le gestionnaire réessaie. Après 30 secondes, le délai d’expiration total annule la requête et votre code obtient un TimeoutRejectedException. Vérifiez que votre application l’intercepte et indique à l’utilisateur ce qui s’est passé.

Tip

Pour tester les mêmes scénarios avec vos propres paramètres de résilience, modifiez les valeurs dans votre appel AddStandardResilienceHandler(options => ...) et réexécutez les mêmes configurations de proxy de développement.

Étape suivante

En savoir plus sur la simulation de limitation sur n’importe quelle API.

Tester si mon application gère correctement la limitation de requêtes

Voir aussi

  • Dernière mise à jour :