> **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