Précisez d’abord quelle est l’erreur
HTTP 429 signifie qu'un fournisseur n'acceptera pas une autre demande pour le moment. Ceci est différent d'un jeton OAuth expiré, d'une autorisation manquante, d'un média non valide ou d'une erreur de plateforme technique. Seules les erreurs correctement classées reçoivent la réparation appropriée.
La réponse peut contenir un indice de nouvelle tentative. S'il manque, le système utilise un recul exponentiel limité avec une répartition aléatoire. Cela signifie que les tâches parallèles ne redémarrent pas en même temps et génèrent immédiatement la limite suivante.
Avant de réessayer, l'idempotence doit être clarifiée
En cas de perte de connexion, on ne sait pas toujours si le fournisseur a déjà accepté la contribution. Une nouvelle tentative aveugle peut alors publier deux fois. Chaque tâche de publication nécessite un identifiant interne stable et - si pris en charge - une clé d'idempotence ou une référence de fournisseur.
Si le résultat n'est pas clair, la tâche passe à un état tel que INCONNU ou VERIFYING. Le système vérifie d'abord le statut du fournisseur et les références existantes. Seule une tentative manifestement non réalisée peut être répétée.
Le recul reste limité et observable
Un plan de nouvelle tentative raisonnable comporte un nombre maximum de tentatives, un temps d'attente maximum et une fin. Chaque tentative enregistre la classe d'erreur, l'heure et la prochaine date limite. Des répétitions interminables masquent un défaut et peuvent entraîner des coûts supplémentaires.
Après des tentatives épuisantes, le message ne sera pas marqué comme un succès. Il reste bloqué ou fait l'objet d'une action de l'utilisateur. Les autres plateformes sont autorisées à continuer à fonctionner tant que leurs tâches sont indépendantes.
- Respecter la nouvelle tentative après
- Utiliser l'intervalle exponentiel avec gigue
- limiter le nombre maximum de tentatives
- pas de répétition si le résultat externe n'est pas clair
- isoler par plateforme
- Rendre les réparations visibles à la fin
Le recours au fournisseur n’est pas toujours possible
Pour les supports de stockage ou le traitement génératif, un autre fournisseur agréé peut remplir le même objectif technique. Cependant, dans le cas de la publication sociale réelle, le compte cible est lié à une connexion à la plateforme. Un changement ne peut pas être publié inaperçu via un autre compte ou outil.
Le repli est donc évalué par type d’action. Une recherche d'image vide peut basculer vers une deuxième source qualifiée. Un droit OAuth manquant nécessite une reconnexion. Un rapport hauteur/largeur non valide nécessite un ajustement du support.
Runbook court pour les opérations
Une équipe doit disposer d’un processus défini pour les erreurs de publication récurrentes. Il réduit les réparations spontanées et rend les rapports d'état compréhensibles.
- Afficher la classe d'erreur et le canal concerné
- Vérifier le statut externe et l'ID du fournisseur
- déterminer une nouvelle tentative sécurisée ou une action spécifique de l'utilisateur
- continuer à travailler en indépendant
- Une fois terminé, synchronisez la file d'attente et le calendrier
- Exclure les doublons entre les ID internes et externes
FAQ
Un 429 doit-il être réessayé immédiatement ?
Non. Vous devez attendre l’avis du fournisseur ou un délai d’attente limité. Les tentatives parallèles instantanées resserrent souvent la limite.
Le travail global peut-il s’arrêter à cause d’une plate-forme ?
Seulement s’il manque une exigence commune en matière de sécurité. Un bug de plateforme isolé ne devrait pas bloquer d’autres publications indépendantes.