16 dossiers RAG en statut « error » — cause : état de session OWA dégradé (arborescence invisible), pas le nommage

Instance auteur : hermes-tt Date : 2026-08-02 Tags : mail, o365, owa, playwright, hermes-mail-browser, nyora-notes-tt, rag, checkpoint, error Statut : valide (diagnostic) — correctif à appliquer

Probleme

16 checkpoints de la table checkpoint de nyora-notes-tt.db sont en statut error (statut générique, distinct de 404/409), tous avec notes_count=0. Chemins concernés :

00 2026|Accor Project
00 2026|Consultations|01/DCZS/2026 Articles Cadeaux ← contient /
00 2026|DR Zone Sud (+ Gabes, Sfax, Tataouine, Tozeur)
Moi / 02 2024|Moi
Moyens Humains
Rapport mensuel
Relance marchés RLA (+ AO 19/2026 Entretien Préventif, AO 27/2026 Entretien des clients FO, Zone Sud) ← 2 contiennent /
01 2025

Deux hypothèses initiales : (H1) les / dans les noms de segments (AO 19/2026, AO 27/2026, 01/DCZS/2026) cassent la résolution ; (H2) les dossiers-conteneurs sans mail direct (DR Zone Sud + 4 gouvernorats, Moi, Moyens Humains, Rapport mensuel, Relance marchés RLA + Zone Sud, 01 2025, Accor Project) sont mal gérés par search_folder(query="*").

Contexte et contraintes

Lecture mail O365 EXCLUSIVEMENT via l'API hermes-mail-browser (http://hermes-mail-browser:8000), Playwright sur un onglet Edge partagé, session persistée dans data/profile/.
Auth 100% manuelle par Nabil via noVNC (port 8810, LAN). Aucun credential O365 stocké.
Pipeline d'ingestion : n8n → O365 → Mimo V2.5 → DeepSeek V4 Flash → nyora-notes-tt (MCP Streamable HTTP pur sur nyora-notes-tt:8000/mcp, 3 outils lecture seule).
La DB nyora-notes-tt.db vit DANS le conteneur du service (pas de bind mount visible) → interrogée via MCP get_checkpoint_status, pas par accès direct au fichier.
Socket Docker inaccessible depuis le conteneur hermes-tt → docker logs impossibles ; diagnostic par reproduction HTTP réelle.

Ce qui NE fonctionne PAS

Tentative	Erreur obtenue	Raison de l'echec
H1 : hypothèse du `/` dans les noms	Réfutée par le runbook `mail-o365-folder-path-disambiguation.md` (31/07) : le séparateur est `\|` PAR CONCEPTION justement parce que les noms contiennent des `/` ; le chemin `02 2024\|RLA\|AO 66/2024 E Curatif\|Notification` avec `/` dans les segments a extrait 7 messages le 31/07	Le `/` n'est pas confondu avec le séparateur ; les segments à `/` étaient déjà résolus avant la régression
H2 : hypothèse des conteneurs sans mail direct	Réfutée : `Accor Project` contient des mails (count:3 via `/search`), `Budget` (dossier done) répond 200 ; le même chemin alterne 200/404/500 entre deux appels sans modification	Le contenu du dossier n'est pas la variable ; c'est l'état de la session qui varie
Reproduction pipeline sur les 16 chemins (noms réels emojis/minuscules)	`404 — Segment 'X' introuvable sous 'Y'. Enfants disponibles : []`	La résolution par noms exacts (emojis inclus) est correcte MAIS l'arborescence des dossiers n'est jamais chargée dans la session
`GET /folders`	`{"count": 0, "folders": []}` — TOUJOURS, sur 5+ appels espacés, y compris après `GET /inbox` racine (200)	`snapshot_folders()` ne voit aucun treeitem → volet de navigation OWA non chargé / replié dans la session Playwright
`GET /inbox?folder_path=00 2026	Accor Project`	HTTP 200 (test A) puis HTTP 404 (test 3) sur le MÊME chemin
`GET /search?q=*&folder_path=00 2026	Accor Project`	HTTP 404 (test B) puis HTTP 200 (test 4) sur le MÊME chemin
Appels répétés / réchauffage (`/folders` ×3, `/inbox` racine puis `/folders`)	`count: 0` persistant	L'état ne se répare pas par simple réchauffage HTTP

Solution validee (diagnostic)

Cause racine identifiée par reproduction HTTP (02/08/2026) :

snapshot_folders() renvoie zéro dossier (/folders → count:0) sur tous les appels → l'arborescence des dossiers OWA n'est PAS chargée/visible dans la session Playwright partagée (volet de navigation replié ou non monté — symptôme déjà documenté dans mail-o365-hermes-mail-browser-inbox-staleness.md et mail-o365-folder-path-disambiguation.md, bug n°2 « volet replié en mode icônes seules ~68px »).
Conséquence : go_to_folder_path() ne peut résoudre AUCUN segment au-delà de la racine → « Enfants disponibles : [] » → 404 pour les chemins profonds, 500 (Internal Server Error, crash non géré) sur certains appels.
Non-déterminisme prouvé : le même chemin répond 200 puis 404 puis 500 sans changement d'appel → l'état du volet/arbre OWA varie au fil des appels dans la session partagée.

Les deux hypothèses initiales sont donc réfutées : ni les / dans les noms (H1), ni le statut « conteneur sans mail direct » (H2) ne sont la cause. La cause est un état de session OWA dégradé côté hermes-mail-browser : l'arborescence des dossiers n'est pas visible pour snapshot_folders(), probablement volet replié suite à une session noVNC manuelle ou après redémarrage sans séquence propre.

Correctif à appliquer (séquence documentée)

Redémarrer proprement le conteneur hermes-mail-browser (séquence du runbook inbox-staleness) :

# Sur le NAS, dans /volume1/docker/hermes-mail-browser :
docker compose stop hermes-mail-browser
rm -f data/profile/SingletonLock data/profile/SingletonCookie data/profile/SingletonSocket
docker compose up -d
# Vérifier :
curl http://192.168.100.33:3110/auth/status   # → authenticated:true, SANS re-auth manuelle
curl http://192.168.100.33:3110/folders       # → count > 0 (arborescence chargée)

Alternative si le redémarrage ne suffit pas : déplier manuellement le volet de navigation OWA via noVNC (port 8810) puis revérifier /folders → count > 0.

Relance des 16 chemins

Une fois /folders → count > 0 confirmé, relancer l'ingestion sur les 16 chemins ci-dessus (réinitialiser les checkpoints error → pending, ou re-déclencher le workflow n8n). Vérification : get_checkpoint_status → les 16 checkpoints passent à done avec notes_count > 0.

Verification

# 1. Arborescence chargée
curl http://hermes-mail-browser:8000/folders
# Résultat attendu : {"count": N, "folders": [...]} avec N > 0 (auparavant 0)

# 2. Résolution d'un chemin précédemment en erreur (déterministe, 3 appels identiques)
curl "http://hermes-mail-browser:8000/inbox?folder_path=00%202026%7CAccor%20Project"
# Résultat attendu : HTTP 200 identique sur les 3 appels (auparavant 200/404/500)

# 3. Checkpoints RAG
# MCP get_checkpoint_status → 16 chemins : statut done, notes_count > 0

Pieges specifiques

Ne pas redémarrer avec docker compose up -d seul : les fichiers SingletonLock/SingletonCookie/SingletonSocket de l'ancien process Edge survivent et bloquent le nouveau. Séquence stop → rm → up obligatoire.
/folders → count:0 est le symptôme sentinelle : si l'arborescence est vide, toute résolution de chemin profond échouera. Toujours vérifier /folders avant d'investiguer un 404.
Non-déterminisme = session, pas nommage : un chemin qui répond 200 puis 404 puis 500 indique un état de session volatil, pas un problème de noms. Ne pas « corriger » les noms en conséquence.
Emojis et casse dans les noms OWA : le pipeline doit envoyer les noms EXACTS (emojis inclus, minuscules réelles, ex. 🧠 consultations) — les noms normalisés sans emojis échouent. Mais ceci est un problème distinct (404 stables), pas la cause des 16 error.
Les 3 chemins à / (AO 19/2026, AO 27/2026, 01/DCZS/2026) : le séparateur | les gère correctement — à surveiller seulement après correctif pour confirmer qu'ils passent en done.

References

hermes-tt/mail-o365-hermes-mail-browser-inbox-staleness.md (24/07/2026) — staleness liste virtualisée, séquence de redémarrage Singleton*
hermes-tt/mail-o365-folder-path-disambiguation.md (31/07/2026) — séparateur |, noms exacts emojis, bug volet replié
hermes-tt/mail-o365-recherche-scroll-virtualisation.md (24/07/2026) — endpoints /search*, virtualisation liste
hermes-tt/mail-o365-search-pas-de-filtre-date.md (30/07/2026) — limites /search
Skill nyora-notes — schéma checkpoints, MCP nyora-notes-tt

8.5 KiB Raw Blame History Unescape Escape