HTTP 429 : comprendre Retry-After et maîtriser les nouvelles tentatives

Identifier le composant qui limite

Consignez heure, ressource, méthode, état, identifiant de requête et en-têtes de temporisation, sans identifiants secrets ni données personnelles. Distinguez API, proxy et CDN ; l'apparence d'une page d'erreur ne suffit pas.

La limite peut porter sur une IP, un utilisateur, une application ou une ressource. Quota par minute, requêtes simultanées et quota quotidien demandent des corrections différentes. Ralentir ne rétablit pas un quota quotidien épuisé.

• Le nombre de tâches ou de répétitions a-t-il augmenté ?
• D'autres services, onglets ou clés partagent-ils le compte ?
• Compte-t-on les requêtes, celles en cours, les jetons ou une autre ressource ?
• La reprise reste-t-elle compatible avec l'échéance de l'utilisateur ?

Lire correctement la durée de Retry-After

La valeur est un entier positif ou nul en secondes, ou une date HTTP. Le nombre 12 signifie 12 secondes, pas des millisecondes. Une date nécessite une horloge fiable ; une date passée ne justifie pas une boucle immédiate.

Respectez le délai minimal du serveur et ajoutez une dispersion aléatoire. S'il dépasse l'échéance de la tâche, arrêtez ou reprogrammez. Ne raccourcissez pas ce délai pour le faire entrer dans un plafond local inférieur.

Budgéter la file commune

Avec 120 requêtes par minute pour tout le compte, 600 nécessitent au moins cinq minutes sans autre activité. Les envoyer en dix secondes puis dormir reste une rafale.

Une cible de 90 par minute vaut 1.5 par seconde, soit environ un départ toutes les 667 millisecondes. Les 600 requêtes demandent 400 secondes hors latence et répétitions. Avec des réponses en 2 secondes, la moyenne vaut 1.5 × 2 = 3 requêtes actives. Un sémaphore borne les opérations en cours ; un régulateur commun borne les départs. Les relances consomment le même quota.

Example workload assumptions:
Account allowance: 120 requests/minute
Operating target: 90 requests/minute = 1.5 requests/second
600 requests / 1.5 requests/second = 400 seconds
Average concurrency at 2 seconds/response: 1.5 × 2 = 3

Espacer les relances avec une part aléatoire

Sans délai valable, une politique peut élargir la fenêtre à une, deux, quatre puis huit secondes, en tirant l'attente au hasard. Cela évite une reprise simultanée des exécutants.

La fonction calcule un délai, pas un client complet. L'appelant doit gérer échéance, plafond de tentatives, annulation et sûreté de répétition. Dans le navigateur, CORS peut imposer d'exposer Retry-After.

function retryDelayMs(retryAfter, attempt, nowMs = Date.now()) {
  const text = String(retryAfter ?? "").trim();
  if (/^\d+$/.test(text)) {
    const milliseconds = Number(text) * 1000;
    return Number.isSafeInteger(milliseconds) ? milliseconds : Infinity;
  }
  if (/^(Mon|Tue|Wed|Thu|Fri|Sat|Sun), \d{2} (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d{4} \d{2}:\d{2}:\d{2} GMT$/.test(text)) {
    const dateMs = Date.parse(text);
    if (Number.isFinite(dateMs)) return Math.max(0, dateMs - nowMs);
  }
  const windowMs = Math.min(8000, 1000 * 2 ** attempt);
  return Math.floor(Math.random() * windowMs);
}
// Example policy: at most 4 retries and a 30-second total deadline.
// If the required wait exceeds the remaining deadline, stop.

Préserver les effets uniques

Lire une ressource n'est pas créer un paiement. Vérifiez l'idempotence et les effets possibles du premier appel. Réutilisez la même clé pour la même opération logique ; une clé neuve à chaque essai peut créer des doublons.

Le SDK peut déjà réessayer. Une boucle extérieure multiplie les appels réels. Comptez les tentatives sur toutes les couches et proposez une reprise ultérieure plutôt qu'une attente infinie pour une action utilisateur.

• Fixer une échéance commune et annuler les tâches en attente.
• Partager les plafonds de simultanéité et de débit.
• Libérer les ressources de réponse avant d'attendre.
• Arrêter en cas de quota épuisé ou d'erreur définitive.
• Consigner tentatives et résultat final.

Vérifier sur un petit lot maîtrisé

Commencez par vingt lectures et comptez appels initiaux, relances, réussites et échecs définitifs. Mesurez espacement et simultanéité. Simulez 429 et Retry-After sans charger un service réel.

Planifiez avec les outils de débit et de simultanéité puis comparez aux limites réelles. Si le problème persiste, cherchez les autres appelants et le type de quota avant d'allonger aveuglément l'attente.