Gérer les 429 sans tempête de retries

Guide de production : Gérer les 429 sans tempête de retries. Il comprend un artefact déterministe, des limites d’échec, des contrôles de déploiement et des sources vérifiées.

Gérer les 429 sans tempête de retries

Guide de production : Gérer les 429 sans tempête de retries. Il comprend un artefact déterministe, des limites d’échec, des contrôles de déploiement et des sources vérifiées.

Décider d’abord

Gérer les 429 sans tempête de retries est un contrat de production explicite, pas une modification isolée. Définissez réussite, échec terminal et rollback avant de déplacer le trafic ; l’artefact sépare preuve et hypothèse.

Commencez par classification, prouvez retry_after avec un cas déterministe et faites de terminal une condition de mise en production.

Artefact réutilisable

Une ligne ne passe que si sa preuve vient de la même requête, fenêtre de test ou version de configuration.

Point de contrôle Preuve à conserver Condition de réussite
classification 429_source:_application,gateway,provider,or_shared_pool Le relevé relie une requête logique et une tentative précise.
retry_after delta-seconds_or_HTTP-date_parsed_against_a_monotonic_deadline La valeur est préservée et comparée exactement à la frontière du protocole.
jitter bounded_random_delay_after_server_guidance La limite est explicite et l’échec est fermé.
attempts one_end-to-end_attempt_budget_shared_by_every_layer La limite est explicite et l’échec est fermé.
concurrency admission_reduced_before_retry_volume_grows La limite est explicite et l’échec est fermé.
terminal final_429_returned_with_request_ID_and_no_hidden_retries Owner, source, date et limite sont consignés.

Exemple détaillé

L’exemple est synthétique et déterministe. Utilisez vos valeurs revues, sans secret ni donnée client.

attempt_budget = 3
for attempt in 1..attempt_budget:
  result = call_once()
  if result.status != 429: return result
  if request.deadline_expired(): break
  delay = parse_retry_after(result.headers) ?? bounded_backoff(attempt)
  reduce_admission_concurrency()
  wait(min(delay + full_jitter(), request.remaining_time))
return terminal_429_without_another_retry()

Procédure de mise en œuvre

  1. Figer requête, réponse, configuration et référence observable.
  2. Exécuter un cas positif déterministe et conserver le résultat complet.
  3. Exécuter le cas négatif ou limite associé.
  4. Relier les tentatives à un ID logique et consigner temps, état final et usage sans contenu sensible.
  5. Déployer sur une cohorte bornée avec critères d’arrêt.
  6. Relire l’état durable et le comportement public ; revenir en arrière si une invariance échoue.

Modes d’échec

Ces échecs invalident le résultat même si le HTTP externe semble réussir :

  • Des retries sans budget amplifient la charge.
  • L’annulation n’atteint ni file ni upstream et continue de consommer.
  • Une réponse texte est prise pour une preuve complète de compatibilité.
  • Prompts, clés ou arguments sensibles entrent dans la télémétrie.

Limite de Modelflare

Modelflare centralise routage compatible OpenAI, clés, groupes, usage et erreurs, mais une route configurée ne prouve aucune capacité optionnelle. Vérifiez modèle et canal par le protocole natif, conservez les zéros explicites et prenez le règlement durable comme vérité de facturation.

La page parente couvre la décision générale et la documentation la configuration actuelle.

Liste avant publication

  • Répondre à la question principale avant le contexte.
  • Nommer un owner pour chaque champ, état, métrique et formule.
  • N’utiliser que des identifiants synthétiques.
  • Conserver structure, code, limites et avertissements dans toutes les langues.
  • Revérifier contrats, support et prix à T-1 ; déplacer la date si un fait change.
  • Avant l’heure, exclure de l’API publique, des routes et du sitemap.

Sources et date de vérification

Sources vérifiées le 2026-08-07 ; elles ne prouvent pas une route non testée.