bolbol
/
nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
nas-runbooks/hermes-nyora/veille-dr-nexum-cron-timezo...

3.5 KiB
Raw Blame History

Cron Hermes ne se relit pas au vol + publish n8n casse : veille Dr Nexum non recue

Date : 2026-07-07 Tags : infra, cron, hermes, n8n, publish, timezone, veille, nyora

Symptome

Veille Dr Nexum (Hermes 3x/jour + workflow n8n) non recue le 06/07 20h ni le 07/07 7h, sur les deux pipelines simultanement.

Cause 1 -- Cron Hermes fige en memoire (jobs.json)

Le service cron de chaque agent Hermes charge jobs.json uniquement au demarrage du container. Une edition directe du fichier (passage de 1x a 3x/jour le 06/07) s'est bien ecrite sur disque, mais le processus tournait toujours avec l'ancien horaire quotidien (11h30 UTC) en memoire -- next_run_at restait fige sur l'ancienne valeur meme un jour apres l'edit.

Fix :

  1. Editer jobs.json (cron expr).
  2. Recalculer et ecrire manuellement next_run_at a la bonne valeur (le daemon ne le fait pas toujours correctement au premier boot suivant).
  3. Redemarrer le container agent correspondant -- nom reel hermes-agent-tt / hermes-agent-nyora / hermes-agent-perso (piege : ne pas confondre avec hermes-workspace-*, qui sont d'autres containers).
  4. Restart via API Portainer : POST /api/endpoints/2/docker/containers/{id}/restart timeout systematiquement sur cette instance -- utiliser stop puis start explicites (2 appels separes).
  5. Verifier apres coup que next_run_at a la bonne valeur.

Portainer : endpoint local = id 2. Auth via 172.17.0.1:9000/api/auth depuis un container (jamais l'IP LAN). Credentials dans hermes-platform/.env.

Cause 2 -- Fuseau horaire (NAS + n8n en UTC, pas Tunis)

Le NAS et n8n tournent en UTC. Tunis = UTC+1 toute l'annee (pas de changement d'heure). Un cron 0 7,12,20 * * * tire a 8h/13h/21h Tunis, pas 7h/12h/20h.

Fix : toujours retirer 1h a l'expression cron pour un horaire "heure de Tunis" -- 0 6,11,19 * * * en UTC pour obtenir 7h/12h/20h Tunis. Applique sur jobs.json (Hermes) et sur le node Schedule Trigger n8n.

Cause 3 -- publish_workflow n8n casse sur un workflow specifique (non systemique)

Un workflow deja actif, modifie via l'outil update_workflow, ne bascule pas automatiquement en production -- update_workflow cree un nouveau versionId (brouillon) mais le workflow continue de servir son activeVersionId existant. Sur ce workflow precis, publish_workflow echouait de facon persistante avec "Version not found", y compris en reessayant depuis l'UI n8n elle-meme (capture d'ecran a l'appui) et apres un unpublish_workflow prealable -- confirme comme un etat corrompu propre a ce workflow (chaine de versions cassee en base), pas un bug de l'outil MCP.

Fix qui a marche : dupliquer le workflow (bouton Duplicate dans l'UI n8n). La copie repart avec une chaine de versions saine et se publie normalement des le premier essai. Renommer la copie pour retirer le suffixe " copy", puis unpublish_workflow + archive_workflow sur l'original casse une fois la copie confirmee active.

Verification obligatoire apres toute modif d'un workflow n8n deja actif : get_workflow_details -> comparer versionId et activeVersionId. S'ils different, le changement n'est PAS en production, meme si l'outil de modification a repondu succes.

Lecon generale

Une reponse "success" d'un outil de modification (update_workflow, edition de jobs.json) ne garantit jamais que le changement est en production. Toujours verifier l'etat reel apres coup : next_run_at recalcule pour un cron Hermes redemarre, activeVersion == draft pour un workflow n8n.