La reprise après redémarrage d’OpenClaw

Le redémarrage d’une passerelle est le moment où un assistant reprend tranquillement le fil ou perd discrètement un travail en cours. OpenClaw en fait une préoccupation de premier plan : les conversations, les transcriptions, les tâches planifiées, les enregistrements de tâches de fond et les messages sortants en file d’attente vivent sur disque et non dans la mémoire du processus. Après un redémarrage, le travail éligible interrompu en plein tour est détecté et repris automatiquement, sans qu’un opérateur ait à intervenir. Les questions intéressantes portent donc sur les bords, par exemple ce qui n’est délibérément pas repris et ce qui se passe quand la reprise échoue encore et encore.

Ce qui survit au redémarrage

• L’historique des conversations réside dans une base SQLite propre à chaque agent et reste intact au redémarrage, si bien que les sessions repartent de la transcription enregistrée au lieu de tout recommencer.
• Les tours de session principale interrompus, les exécutions de sous-agents et les tâches de fond sont tous réconciliés depuis SQLite après le démarrage, le registre des sous-agents est restauré, les exécutions de fond orphelines sont récupérées ou marquées perdues, et les livraisons sortantes en file sont vidées puis réessayées.
• Les tâches planifiées persistent dans un magasin cron SQLite et le planificateur se réarme au démarrage, tandis qu’une sentinelle de redémarrage envoie un suivi unique à la session qui avait demandé ce redémarrage.
• Les terminaux de la passerelle sont la nette exception, car ils vivent dans la mémoire du processus, se terminent avec l’ancien processus et ne sont récupérés ni pour les opérateurs ni pour les agents.

La reprise est toujours active et ne demande normalement aucune intervention manuelle.

Vider avant de s’arrêter

Un redémarrage demandé ne tue pas immédiatement le travail en cours. La passerelle cesse d’accepter de nouveaux travaux, puis attend la fin des tours d’agent actifs et des tâches de fond, dans la limite d’un budget de vidange fixé à cinq minutes par défaut, si bien que la plupart des redémarrages n’interrompent rien du tout. Les réponses aux commandes de nœud en attente restent acceptées pendant la vidange, y compris le nettoyage des workers lancé par l’arrêt, même si chaque réponse doit correspondre à son invocation vivante, à sa connexion de nœud, à sa génération d’appairage et à son cycle de vie propriétaire. Seul le travail qui ne peut pas finir dans ce budget, ou une exécution coupée par un redémarrage forcé ou un plantage, est abandonné, et chaque session concernée est marquée pour reprise avant cela. Sous Linux, l’unité systemd doit utiliser le mode de terminaison mixte pour que le premier signal d’arrêt n’atteigne que la passerelle, car les anciennes unités en mode groupe de contrôle signalent immédiatement les runtimes enfants et peuvent interrompre un tour avant la fin de la vidange. Les messages qui arrivent pendant la fenêtre de vidange sont rejetés avec une erreur de redémarrage explicite plutôt que mis en file dans un processus mourant. Les avertissements de migration au démarrage n’empêchent pas la passerelle de démarrer : elle les journalise une fois et démarre en mode dégradé, et les commandes status et doctor montrent le rapport d’avertissement de la passerelle en cours d’exécution. Les erreurs qui rendent un état requis impossible à lire sans risque arrêtent toujours le démarrage.

Comment une interruption est détectée

• À l’admission du tour, la passerelle ajoute le message de l’utilisateur, marque la session comme en cours et enregistre sa revendication de livraison de reprise dans une seule transaction SQLite, avant tout appel au modèle et tout point d’ancrage de réponse.
• À l’arrêt, chaque session ayant une exécution active reçoit un marqueur de reprise dans le magasin de sessions avant que l’exécution ne soit abandonnée, ce qui couvre le chemin ordinaire de vidange.
• Au démarrage, la passerelle parcourt les magasins de sessions à la recherche de sessions qui se déclarent encore en cours sans propriétaire vivant dans le nouveau processus, ce qui rattrape les plantages durs et les arrêts brutaux sans code d’arrêt exécuté, et les fichiers de verrou de transcription périmés sont nettoyés au passage.

Quelques secondes après le démarrage, la passerelle réexpédie chaque session marquée avec un message système synthétique indiquant que le tour précédent a été interrompu par un redémarrage. Si une réponse finale avait déjà été produite sans être livrée, son texte est inclus pour que l’agent l’envoie au lieu de refaire le travail. Voir la reprise des sessions interrompues par OpenClaw pour le tableau d’ensemble, et les vérifications doctor d’OpenClaw pour la réparation quand un indicateur d’abandon périmé entre en conflit avec une session neutralisée.

Pourquoi le budget est borné

Le choix de conception le plus important ici est le refus de réessayer sans fin. Chaque cycle de session principale interrompu porte un budget durable de trois tentatives d’envoi automatique facturées, conservé d’un redémarrage à l’autre, et une tentative est facturée avant l’envoi, remboursée quand la passerelle rejette explicitement la demande avant acceptation, et conservée quand un résultat postérieur à l’envoi reste incertain. Une fois ce budget épuisé, la session est neutralisée et vous en démarrez une de remplacement, au lieu de regarder une boucle tourner indéfiniment. Le même instinct se retrouve dans le disjoncteur de boucle de plantage, où trois démarrages non propres en cinq minutes suppriment les services annexes à démarrage automatique lors du démarrage suivant, alors que le plan de contrôle démarre quand même. Il se retrouve aussi dans la restriction d’outils choisie avant une reprise, puisque les états aux effets de bord ambigus continuent normalement avec des outils sûrs au redémarrage, afin que le modèle puisse inspecter un résultat sans rejouer un effet externe. Lire cette page à côté de la référence de configuration de la passerelle rend l’arbitrage plus clair, et le signal de frappe protégé explique pourquoi un tour repris peut encore afficher un indicateur de frappe sur le canal d’origine.

Sur Diali

Sur Diali, chaque client fait tourner son propre assistant et son état vit sur un volume persistant, si bien que le comportement de reprise décrit ici s’applique à un vrai redémarrage et non à une page blanche ; des instantanés quotidiens et une restauration en un clic sont disponibles grâce à l’option Sauvegardes (incluse avec Max). La configuration du runtime est générée depuis le tableau de bord et remplacée à chaque version. Voir OpenClaw hébergé sur Diali pour ce que nous hébergeons, et La sécurité Diali pour la façon dont nous traitons cet état.

• Conversations, tâches et files vivent sur disque, donc rien ne se perd.
• Un redémarrage ordonné vide d’abord, jusqu’à cinq minutes, avant d’abandonner.
• Trois tentatives automatiques échouées neutralisent la session sans boucler.