Les types d’événements des hooks d’OpenClaw

Un hook ne vaut que l’événement auquel il s’abonne, et les événements internes d’OpenClaw diffèrent sur deux points qui comptent : si le producteur attend le gestionnaire, et quel contexte il lui transmet. Les gestionnaires s’abonnent à une clé exacte ou à une famille nue, commande, session, agent, passerelle ou message, et un abonnement de famille reçoit toutes ses actions, si bien qu’abonner un gestionnaire à la fois à la famille et à une clé exacte l’appelle deux fois. Voici les événements de chaque famille, leur comportement d’attente, les points saillants du contexte, et les limites que la documentation prend soin d’énoncer.

Commandes, sessions, agents

• Les commandes de nouvelle session et de réinitialisation sont attendues quand elles sont traitées depuis une commande de chat autorisée ou une opération de session de la passerelle, et l’arrêt est attendu après la demande d’interruption sans livraison de réponse de hook ; l’événement de réinitialisation automatique de session se déclenche quand la politique quotidienne ou d’inactivité remplace une session et est distribué indépendamment du tour successeur.
• La compaction a deux clés exactes, avant et après une compaction réussie, toutes deux attendues ; il n’y a ni famille ni joker de compaction, et la compaction peut être sautée ou échouer après son événement avant tandis que les relances peuvent l’émettre de nouveau.
• L’événement de correctif de session est une notification asynchrone quand un correctif de passerelle autorisé est appliqué ou qu’un chemin de sélection de modèle pris en charge conserve un changement, y compris la commande de modèle, le sélecteur et les changements par l’outil d’état de session, mais pas une consultation d’état en lecture seule ; il porte l’entrée après opération et le correctif tel que demandé, pas un différentiel calculé, et ce n’est pas une notification pour chaque écriture du magasin de sessions.
• L’événement d’amorçage de l’agent est attendu pendant la résolution de l’amorçage de l’espace de travail avant l’injection du contexte : son contexte contient le répertoire de l’espace de travail et une liste modifiable d’enregistrements d’amorçage avec nom, chemin, indicateur d’absence et contenu facultatif, qu’un gestionnaire peut remplacer ou étendre tandis que la déduplication finale, le filtrage de confidentialité et les budgets de contexte s’appliquent toujours.

Ce sont des points d’observation, pas un audit complet du transport ni un moyen de bloquer le traitement des messages.

Événements de passerelle et de messages

Le démarrage est planifié après le chargement des hooks et le démarrage des canaux et ne retarde pas la liaison initiale de la passerelle. L’arrêt se déclenche quand l’arrêt commence, avant le démontage des canaux et des extensions, et le pré-redémarrage quand l’arrêt a un délai de redémarrage attendu fini ; les deux ont des attentes bornées, cinq secondes et un budget distinct de dix secondes, qui bornent l’attente de l’appelant et non le travail du gestionnaire, un dépassement n’annule pas la promesse, et avant de fermer l’état partagé la passerelle attend l’achèvement réel, si bien qu’un gestionnaire qui ne se règle jamais peut empêcher l’arrêt en cours de processus de se terminer. Ni le travail d’agent en file ni la livraison des messages ne sont garantis de finir avant l’arrêt. La famille des messages a quatre points d’observation asynchrones : reçu, quand une distribution entrante acceptée a une clé de session ; transcrit, quand le prétraitement avant l’agent a un texte de transcription audio non vide ; prétraité, quand le prétraitement des médias et des liens s’est terminé ou a été sauté ; et envoyé, quand un propriétaire de livraison rapporte une issue. Toute mise à jour de transport ou tout envoi de bas niveau n’en produit pas un : les distributions supprimées ou en double et les chemins sans clé de session peuvent les omettre, les chemins rapides de commandes natives peuvent sauter les événements de prétraitement, et prétraité signifie que la phase a été passée, pas que chaque pièce jointe a été comprise.

Points saillants du contexte

• Les événements de commandes portent l’identifiant de l’agent, l’entrée de session et l’entrée précédente, la source de la commande, l’expéditeur, l’espace de travail et le chemin du magasin sur le chemin du chat, tandis que les appelants de la passerelle omettent l’expéditeur et utilisent leurs propres noms de source ; la documentation recommande l’entrée précédente pour la session remplacée, puisque les chemins du chat et de la passerelle émettent à des moments différents d’une réinitialisation, et une valeur de fichier de session peut être un identifiant de transcription plutôt qu’un chemin lisible.
• Le contexte de message reçu contient l’expéditeur, le contenu, le canal et, en option, l’horodatage, le compte, la conversation, l’identifiant de message, des tableaux de médias structurés et des métadonnées comme le fil, les noms d’expéditeur, de guilde et de canal ; le contenu préfère un corps de commande non vide, puis le corps brut. Transcrit et prétraité ajoutent la transcription, le corps enrichi préparé pour l’agent et des indicateurs de groupe, et quand la mise en attente des médias est en cours le tableau des médias est retenu tandis que les pièces jointes d’origine sont décrites, donc les chemins distants ne doivent pas être traités comme des fichiers locaux.
• Le contexte d’envoi contient la cible, le contenu, un indicateur de succès, le canal et, en option, une erreur et des identifiants ; un succès faux rapporte un échec sur un chemin qui a émis une issue, tandis que l’absence d’événement ne prouve ni succès ni échec, la livraison peut rapporter une issue par charge logique plutôt que par morceau, un échec partiel peut inclure un identifiant pour une partie déjà envoyée, et un résultat d’envoi ne prouve pas que le destinataire a lu quoi que ce soit, donc ne renvoyez jamais aveuglément en cas d’échec.

Hooks et webhooks dans OpenClaw explique comment écrire et enregistrer un gestionnaire pour ces clés, et La boucle d’agent d’OpenClaw où les événements attendus se placent dans une exécution.

Clés inconnues et l’autre système de hooks

Un abonnement inconnu, comme une clé de commande mal orthographiée, est tout de même enregistré, mais le chargeur avertit et la commande d’information le signale, et le cœur ne l’émet jamais ; une clé personnalisée ne se déclenche que si du code personnalisé l’émet. L’événement d’arrêt observe le traitement de l’annulation et n’est pas une barrière naturelle de finalisation de l’agent ; ce contrat appartient aux hooks typés des extensions. Fenêtre de contexte et compaction dans OpenClaw couvre les phases que les deux clés de compaction entourent, et Les extensions d’OpenClaw le système de hooks typés qui porte le contrat de finalisation.

Sur Diali

Sur Diali, ces événements se déclenchent dans la passerelle de l’assistant comme partout ailleurs, et parce que nos releases redémarrent cette passerelle, un gestionnaire d’arrêt qui ne se règle jamais retiendrait le redémarrage, donc gardez les gestionnaires bornés. OpenClaw hébergé sur Diali est l’assistant et La passerelle OpenClaw expliquée le processus qui émet chacune de ces clés.

• Clé exacte ou famille nue, jamais les deux sur un gestionnaire.
• Attendu pour les commandes, la compaction et l’amorçage ; observé pour les messages.
• Un événement manquant ne prouve rien ; une issue d’envoi ne prouve aucune lecture.