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