Files
nas-runbooks/hermes-tt/mail-o365-16-dossiers-error-etat-session-owa.md
T

9.2 KiB
Raw Blame History

CORRIGE le 02/08/2026 -- le diagnostic ci-dessous (etat de session OWA degrade / volet replie) est infirme. La cause reelle : un clic d'expansion non idempotent dans go_to_folder_path (bascule un dossier deja deplie vers ferme a chaque appel), plus deux bugs annexes (/folders utilisait inner_text() non fiable ; aucun verrou entre requetes sur la page Playwright partagee). Corrige, deploye, verifie 22/22. Voir mail-o365-toggle-expand-non-idempotent-fix.md pour le diagnostic complet et la preuve empirique. La sequence de redemarrage avec purge Singleton* proposee plus bas dans ce document ne corrige pas le probleme durablement -- a ne plus appliquer pour ce symptome.


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 :

  1. 00 2026|Accor Project
  2. 00 2026|Consultations|01/DCZS/2026 Articles Cadeaux ← contient /
  3. 00 2026|DR Zone Sud (+ Gabes, Sfax, Tataouine, Tozeur)
  4. Moi / 02 2024|Moi
  5. Moyens Humains
  6. Rapport mensuel
  7. Relance marchés RLA (+ AO 19/2026 Entretien Préventif, AO 27/2026 Entretien des clients FO, Zone Sud) ← 2 contiennent /
  8. 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) :

  1. snapshot_folders() renvoie zéro dossier (/folderscount: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 »).
  2. 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.
  3. 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 /folderscount > 0.

Relance des 16 chemins

Une fois /folderscount > 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.
  • /folderscount: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