runbook: cron n8n orphelin (ingestion continue) cause reelle instabilite hermes-mail-browser
This commit is contained in:
hermes-tt
@@ -0,0 +1,77 @@
|
|||||||
|
# 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
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 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)
|
||||||
Reference in New Issue
Block a user