La politique de relance d’OpenClaw

Les fournisseurs limitent le débit, les connexions se coupent, un flux se termine avant son dernier événement. La politique de relance d’OpenClaw décide de la suite, et ses trois objectifs sont simples : relancer par requête HTTP plutôt que par flux en plusieurs étapes, préserver l’ordre en ne relançant que l’étape courante, et ne jamais dupliquer une opération non idempotente. Voici les valeurs par défaut des canaux, le budget de récupération des modèles et la façon dont il poursuit une exécution, ce qui est exclu de ce budget, le plafond des SDK sur les longues attentes, les particularités de Discord et Telegram, et le budget distinct de la file sortante durable.

Valeurs par défaut des canaux

• Trois tentatives avec dix pour cent de gigue pour chaque enveloppe de canal ; un délai minimal de quatre cents millisecondes pour l’enveloppe partagée, Telegram et tout canal sans surcharge, et de cinq cents pour les envois et appels REST de Discord.
• Un plafond de délai de trente secondes pour l’enveloppe partagée et les envois Discord, et de cinq minutes pour les appels à l’API REST de Discord.
• La boucle de reconnexion du WebSocket de la passerelle Discord est distincte : jusqu’à cinquante tentatives de reconnexion avec un recul exponentiel de deux secondes à un plafond de trente secondes, sans gigue.
• Discord relance les limites de débit, les délais de requête, les erreurs serveur et les défaillances de transport passagères comme les résolutions DNS, les réinitialisations de connexion et les fermetures de socket, en utilisant le retry-after de la plateforme quand il existe ; Telegram relance la même classe d’erreurs passagères, et les erreurs d’analyse HTML ou Markdown ne sont pas relancées mais retombent en texte brut dès la première tentative. Les délais d’aucun des deux canaux ne sont configurables.

Relancer par requête HTTP, pas par flux en plusieurs étapes.

Le budget de récupération des modèles

Les exécutions d’agent se remettent des limites de débit temporaires, des surcharges et des défaillances de fournisseurs avant d’afficher une erreur terminale : les limites de débit reçoivent jusqu’à dix tentatives au total, les autres défaillances passagères permettent huit relances dans une fenêtre de quatre-vingt-dix secondes, le recul commence autour d’une seconde, croît de façon exponentielle et ajoute de la gigue, et les indications de rythme des fournisseurs comme les en-têtes retry-after ou un message invitant à réessayer fixent l’attente minimale même au-delà du plafond de recul de trente secondes. L’annulation et l’échéance de l’exécution arrêtent toujours la récupération. La récupération poursuit la transcription existante avec une instruction de préserver le travail accompli et d’inspecter les actions interrompues avant de les répéter, si bien qu’une limitation après une activité d’outils ou une sortie partielle se récupère sans resoumettre la requête de l’utilisateur ; l’exécution montre un seul indicateur de relance passagère, reste annulable, et les tentatives récupérées ne laissent aucune erreur d’assistant conservée, seul un échec terminal en garde une. Dans l’environnement embarqué, un délai d’inactivité du modèle après une activité d’outils utilise la même récupération quand chaque outil du dernier lot a un résultat enregistré et que l’exécution est réglée, en gardant les outils disponibles pour la tentative suivante ; un flux Responses qui se termine avant son événement terminal est aussi éligible, même avec un appel d’outil inachevé, et des arguments d’outil partiels ne sont jamais exécutés.

Hors du budget

• Les échecs de facturation, les erreurs d’authentification et les refus de fournisseurs n’utilisent jamais le budget passager, et les fenêtres d’usage épuisées, abonnement, jour, semaine ou mois, partent directement vers le profil d’authentification ou le modèle de repli éligible ; un long retry-after seul ne prouve pas qu’une fenêtre d’usage est épuisée, donc les limitations temporaires respectent toujours l’attente minimale du fournisseur. Le contrôleur de basculement de modèle possède le budget et, une fois celui-ci dépensé, suit les chemins de repli ou fait remonter l’échec final ; les harnais natifs peuvent relancer en interne d’abord, séparément de ce budget de poursuite.
• Pour les SDK qui gardent des relances internes, comme les clients Anthropic et OpenAI, un retry-after de plus de soixante secondes fait injecter par OpenClaw un en-tête demandant au SDK de ne pas relancer, pour que le contrôle revienne vite ; une variable d’environnement relève le plafond ou le désactive pour que le SDK dorme lui-même pendant les longues attentes. Les erreurs SSE de ChatGPT gardent ensemble le statut HTTP et le retry-after pour qu’un message inconnu reste relançable, et le transport ChatGPT se reconnecte une fois sur une erreur de limite de connexions avant de diffuser.
• Le réglage de session embarquée du nombre maximal de relances du fournisseur surcharge le budget de récupération, zéro désactivant les relances tandis que les limites de débit restent plafonnées à dix tentatives ; c’est un réglage de session, pas une clé du fichier de configuration, et il ne configure pas les relances des harnais natifs.

Le basculement de modèle d’OpenClaw possède le budget décrit ici et décide de la suite quand il s’épuise, et La file de commandes d’OpenClaw est là où une étape relancée attend son tour.

Livraison sortante durable

La file sortante durable a son propre budget de tentatives de livraison. Quand une livraison utilise une réclamation de producteur, la réservation vérifie le propriétaire exact et son bail avant de facturer une tentative, une réclamation expirée ou remplacée ne dépense pas le budget restant, et la récupération peut acquérir une nouvelle réclamation avant de relancer. Les baux de producteur durent soixante secondes et se renouvellent toutes les vingt tant que le propriétaire est actif, ce qui tolère de brefs blocages de la passerelle ; la récupération d’un producteur disparu attend l’expiration de son dernier bail, et l’expiration d’un bail n’efface jamais la preuve qu’un envoi a déjà commencé, donc ces entrées exigent encore une réconciliation avant rejeu. Les relances s’appliquent par requête, envoi de message, téléversement de média, réaction, sondage ou autocollant, et les flux composites ne relancent jamais les étapes accomplies. Streaming et découpage dans OpenClaw couvre les envois que ce budget protège, et La boucle d’agent d’OpenClaw l’échéance d’exécution qui arrête la récupération.

Sur Diali

Sur Diali, les budgets de relance tournent à leurs valeurs amont par défaut dans l’assistant, et la route de modèle gérée se place devant le fournisseur, si bien qu’une erreur terminale dans le chat est une erreur qui a survécu à tout le budget. OpenClaw hébergé sur Diali est l’assistant et Modèles et fournisseurs d’OpenClaw couvre les fournisseurs auxquels le budget s’applique.

• Par requête, étape courante seulement, jamais de doublon.
• Dix tentatives pour les limites de débit, huit en quatre-vingt-dix secondes sinon.
• Facturation, authentification et refus partent droit en repli.