Un délai d’expiration cron ne prouve pas que votre action OpenClaw a échoué

Si un travail cron expire après l'envoi d'un message, la publication de contenu ou la demande de déploiement, OpenClaw sait que l'exécution a échoué. Il peut ne pas savoir si le fournisseur a accepté l'action.

Cette distinction est importante car la documentation actuelle sur les tâches planifiées d'OpenClaw indique que les échecs ponctuels transitoires peuvent être réessayés, tandis que les échecs récurrents utilisent un backoff exponentiel. Rejouer l'action sans vérifier auprès du fournisseur peut créer des doublons.

Traitez un délai d'attente ambigu comme inconnu, et non comme échoué :

préparé -> tenté -> confirmé -> confirmé_absent -> inconnu -> réconcilier

Avant l'écriture, conservez la tâche, l'effet prévu, la cible, le hachage de la charge utile et la clé d'opération. Utilisez une clé d'idempotence du fournisseur si elle est prise en charge.

Après un délai d'attente, interrogez le fournisseur faisant autorité en utilisant son reçu, sa clé d'opération ou son identité de ressource naturelle. Ne réessayez qu'après avoir confirmé que l'effet est absent. Si l'absence ne peut pas être prouvée, arrêtez-vous pour examen.

Les actions de publication, de déploiement, de paiement, de suppression et autres doivent conserver leurs limites d'approbation existantes.

La documentation d'audit d'OpenClaw traite déjà inconnu comme un état de non-succès explicite lorsqu'aucun résultat terminal faisant autorité n'est disponible. C'est le modèle opérationnel approprié pour les écritures externes ambiguës.

Un test utile est un point de terminaison sandbox qui accepte une seule écriture mais retient la réponse. Le workflow doit enregistrer inconnu, éviter une deuxième écriture, réconcilier le premier objet, puis le classer comme confirmé.