Une nouvelle tentative peut être utile lorsqu'une connexion est brièvement interrompue, mais elle peut aggraver une panne lorsque chaque client répète son travail en même temps. Une politique de nouvelle tentative fiable est sélective, limitée et sait si l'opération peut être répétée en toute sécurité.

Décidez si une nouvelle tentative est sûre

  • Réessayez les échecs de connexion temporaires et les réponses de surcharge documentées, pas toutes les erreurs de client ou de validation.
  • Réessayez une mutation uniquement lorsque le serveur prend en charge un mécanisme d'idempotence ou que l'opération peut être répétée en toute sécurité.
  • Respectez Retry-After lorsque le serveur le fournit.
delay = min(maxDelay, baseDelay * 2^attempt) + randomJitter

Fixez une limite ferme

Choisissez un nombre maximum de tentatives et un délai global. Arrêtez-vous lorsque l'appelant annule, signalez clairement l'échec final et enregistrez une métrique pour le nombre de tentatives plutôt que d'enregistrer les données de demande sensibles.

Testez la politique avec une horloge déterministe et une séquence de résultats simulés. Vérifiez qu'une panne prolongée ne crée pas de travail illimité et ne fait pas attendre un utilisateur indéfiniment.