4.4 KiB
Cron n8n orphelin (ingestion continue nyora-notes-tt) : boucle infinie sur folders error_409/404, cause reelle de la lenteur hermes-mail-browser
Instance auteur : hermes-tt Date : 2026-08-02 Tags : n8n, hermes-mail-browser, nyora-notes-tt, cron, stabilite Statut : valide
Probleme
hermes-mail-browser semblait instable/lent (deja documente hier : 20/21 timeouts sur /search profonds). Aujourd'hui, un test de telechargement de PJ a semble bloquer 3+ minutes sur un simple /search. Diagnostic initial : suspicion de probleme structurel OWA/Playwright.
Diagnostic reel
Les logs docker logs hermes-mail-browser montrent un appel GET /search?q=*&folder_path=00 2026|Divers toutes les 10 minutes, exactement, depuis le 31/07 (source IP 172.27.0.34 =
nyora-notes-tt). 292 occurrences. n8n:search_executions sur le workflow correspondant
(Hovzm2wTOOJFxzpb, "nyora-notes-tt -- Ingestion continue") confirme : 292 executions, toutes
marquees "success" (le noeud HTTP a neverError:true, donc un 409 ne fait pas echouer
l'execution n8n -- invisible dans le monitoring standard).
Le workflow : Planification continue (10 min) -> GET /pending-folders?limit=1 ->
POST /ingest sur le dossier recupere. Conçu pour "s'arreter seul quand tout est done" --
mais les statuts error_409 (5 dossiers, doublons ambigus) et error_404 (dossiers vides
confirmes) sont des etats finaux legitimes, jamais retraitables avec succes. Le dossier
"00 2026|Divers" (error_409) revient donc systematiquement en tete de /pending-folders,
le workflow le re-ingere en boucle, obtient un 409, ne progresse jamais -- la condition
d'arret ("plus rien en pending/error") ne se declenche donc jamais non plus.
Consequence : contention reguliere (toutes les 10 min, ~10-90s par execution) sur la page Playwright partagee de hermes-mail-browser, pour un travail strictement inutile.
Ce qui n'etait PAS la cause (verifie, pour eviter de re-chasser cette piste)
| Hypothese | Verification | Resultat |
|---|---|---|
| Fuite memoire Chromium / ressources hermes-mail-browser | docker stats |
1 Go RAM / 19 Go, CPU ~0%, uptime 8h -- sain |
| /search reellement bloque/casse | Test instrumente (-u, timing explicite) apres arret du cron |
search ~35s, list_attachments ~10-15s/message -- conforme aux baselines deja documentees (mail-o365-search-pas-de-filtre-date.md) |
| Le "blocage" de 3 min pendant le test PJ | Logs serveur hermes-mail-browser au meme timestamp | La requete a bien progresse (200 OK x8), c'etait un faux positif cote client (stdout bufferise sur pipe ssh/docker exec sans -u, aucune visibilite temps reel) |
Solution validee
# Identifier le workflow via n8n MCP : search_workflows puis get_workflow_details
# Desactiver :
n8n:unpublish_workflow(workflowId="Hovzm2wTOOJFxzpb")
Verification : plus aucune ligne 172.27.0.34 recurrente a intervalle de 10 min dans les
logs hermes-mail-browser apres desactivation.
Piege generique a retenir
Toute boucle n8n avec condition d'arret "automatique" basee sur un etat DB (type
/pending-folders jusqu'a vide) doit garantir une VRAIE terminaison, pas juste supposer que
la source se tarira. Un statut d'erreur "final" (409 ambigu, 404 confirme vide) n'est pas
la meme chose qu'un statut "en attente de retry" -- si le endpoint source ne distingue pas
les deux, la boucle ne se videra jamais. Corollaire : neverError:true sur un noeud HTTP
masque ce genre de boucle inutile dans le monitoring n8n standard (toutes les executions
semblent "success") -- verifier le CONTENU des reponses, pas seulement le statut d'execution,
pour tout workflow recurrent cense s'auto-arreter.
Avant de blamer un service externe (ici hermes-mail-browser/OWA) pour de la lenteur ou de
l'instabilite persistante, verifier D'ABORD s'il existe un consommateur interne recurrent
(cron n8n, watchdog, boucle de retry) qui genere du bruit de fond -- docker logs filtre par
IP source est souvent le moyen le plus rapide de le confirmer ou de l'ecarter.
References
hermes-tt/mail-o365-search-pas-de-filtre-date.md(30/07/2026) -- baseline timing /search deja mesuree (~35-40s/appel)hermes-tt/nyora-notes-tt-backup-wal-moteur-mixte.md(02/08/2026) -- incident precedent du meme jour, meme famille de lecon (verifier le comportement reel avant de blamer l'infra sous-jacente)- Workflow n8n
Hovzm2wTOOJFxzpb(desactive, pas supprime -- conserve pour historique)