SOP Fan-In : Cron

Intégré. Les déclencheurs cron sont distribués par le cycle périodique de maintenance SOP ; il s’agit donc d’un mécanisme d’interrogation plutôt que d’un minuteur par planification. Leur déclenchement nécessite ce cycle, lancé par un zeroclaw daemon ou par le superviseur zeroclaw channel start (compilé avec la fonctionnalité agent-runtime, sop.sops_dir défini sur une valeur non vide (non défini par défaut, ce qui désactive l’exécution SOP ; la valeur documentée est shared/sops), et sop.maintenance_interval_secs différent de zéro, par défaut 60). Le zeroclaw gateway start autonome ne lance pas le cycle de maintenance et ne déclenche donc pas les déclencheurs cron ; une passerelle hébergée dans le démon le fait, car le démon lance le cycle. Les planifications sont analysées une seule fois au démarrage ; une SOP ajoutée alors que le démon est en cours d’exécution nécessite un rechargement avant que son déclencheur cron ne prenne effet.

Un déclencheur cron s’exécute sur une fenêtre de temps décrite par une expression cron. Les expressions invalides échouent de manière restrictive lors de l’analyse et de la construction du cache.

Déclencheur

Déclenchement basé sur le temps. En direct : distribué par le tick de maintenance SOP (chemins daemon / démarrage de canal).

Charger et vérifier le SOP :

zeroclaw sop validate

zeroclaw sop list
zeroclaw sop show <name>

Exécution

Une exécution démarrée par cron est menée à son terme sans boucle d’agent attachée. Le tick de maintenance transmet chaque ExecuteStep démarré au pilote d’exécution headless, qui exécute le corps de l’étape comme un tour d’agent et fait avancer l’exécution ; les actions DeterministicStep sont acheminées à la place vers le pilote déterministe du moteur. Une exécution qui atteint un point d’approbation ou un point de contrôle se met en attente à cet endroit, exactement comme sous un agent en direct.

Deux contraintes s’appliquent au tour d’étape, toutes deux en mode fermé (fail-closed) :

• Le SOP doit désigner son agent propriétaire, et cet agent doit être activé. Définissez agent dans SOP.toml (ou agent sur une étape individuelle, qui le remplace) avec un alias d’agent configuré. Une exécution cron n’a aucun tour d’agent ambiant dont elle pourrait hériter une identité ; un procédé sans propriétaire est donc rejeté dès sa rédaction, et le pilote refuse l’étape plutôt que de l’exécuter sous un autre agent configuré. Un alias non configuré, ou configuré avec enabled = false, est refusé de la même manière : désactiver un agent le retire également des tâches non supervisées. L’étape s’exécute avec le fournisseur, l’espace de travail, les outils et le profil de risque de cet agent.
• La portée d’outils de l’étape est appliquée, y compris dans les exécutions enfants. Les outils de contrôle SOP (sop_execute, sop_advance, sop_approve) sont toujours retirés d’un tour d’étape, afin qu’une exécution automatique ne puisse pas se piloter elle-même. Lorsque sop.step_scope_enforce est défini, le scope déclaré de l’étape restreint davantage la surface disponible. Un agent enfant lancé par l’étape hérite des mêmes exclusions : en lancer un ne permet donc pas de contourner les limites de l’étape.

Les pilotes cron en cours d’exécution appartiennent à la génération du démon qui les a démarrés. Lors d’un rechargement, le démon arrête le tick de maintenance, laisse les pilotes en cours se terminer avec la configuration sous laquelle ils ont démarré (jusqu’à 30 secondes), puis interrompt les pilotes restants et attend jusqu’à 5 secondes supplémentaires qu’ils s’arrêtent. Ainsi, dans le cas courant, aucune étape ne chevauche deux configurations.

L’annulation est coopérative : une tâche s’arrête à son prochain await, et une tâche qui n’en atteint aucun pendant ce délai de grâce continue de s’exécuter. Le rechargement n’attend pas celle-ci : la génération suivante démarre en parallèle, et le pilote continue d’utiliser l’ancienne configuration et le moteur précédent jusqu’à ce qu’il cède la main. Un tel pilote est consigné (still_running) et transmis à la génération suivante plutôt que détaché, afin qu’il reste suivi et soit vérifié à chaque rechargement jusqu’à sa fin. Considérez les entrées still_running répétées comme le signe qu’une étape bloque sans céder la main.

Voir aussi

• Vue d’ensemble du fan-in
• Syntaxe