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

121 lines
9.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
> **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](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 | Non-déterminisme : l'état du volet varie entre les appels |
| `GET /search?q=*&folder_path=00 2026|Accor Project` | HTTP 404 (test B) puis HTTP 200 (test 4) sur le MÊME chemin | Non-déterminisme confirmé, indépendant de l'endpoint |
| 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** (`/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 »).
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) :
```bash
# 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
```bash
# 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