nas-runbooks/hermes-tt/nyora-notes-tt-message-id-elem-id-volatile-08-08-2026.md

nyora-notes-tt : elem_id OWA VOLATILE — le message_id natif par-message n'existe pas via scraping DOM

Date : 08/08/2026 Instance : hermes-tt Statut : PISTE FERMÉE (elem_id abandonné) — conversation_id (data-convid) + fix retry /search conservés Fichier : /volume1/docker/nyora-notes-tt/hermes_mail_client.py (_parse_item, search_folder)

Objectif initial

Remplacer le message_id du pipeline mail RAG (jusqu'ici msg_<sha256(subject|date|sender)[:16]>) par un identifiant natif par-message stable, pour un ancrage propre (dédup, liaison RAG). hermes-mail-browser avait été patché pour exposer sur /search deux attributs DOM OWA en plus de raw_text/aria_label : elem_id (attribut id de la ligne) et attrs (string pipe-délimitée contenant notamment data-convid=…).

Le faux positif (à ne pas reproduire)

Un premier « test de stabilité » avait conclu que elem_id était stable et unique par message (« vérifié sur 3 appels /search séparés, requêtes différentes, même message → même elem_id »), avec un exemple de valeur base64 type AQAAAAAAAQwCAAAFYk58JQAAAAA=.

Ce test était insuffisant : un seul message, toujours en position 0 de la liste, sur des appels rapprochés. OWA (SPA React) ne re-rend pas forcément la liste virtualisée entre deux appels rapprochés → le même DOM (donc le même id volatile) est réutilisé → stabilité illusoire. C'est le piège classique du test à un seul échantillon.

Le test rigoureux (qui infirme)

Deux appels /search query identique (q="*"), même dossier (02 2024|DR Zone Sud|Tozeur, 20 messages), appariement des messages par raw_text (identité stable pour du mail 2024) :

Mesure	Résultat
elem_id identique pour le même message entre 2 appels	0 / 19
Recouvrement des ensembles d'elem_id (|A ∩ B|)	0 (|A|=17, |B|=17, disjoints)
Même index → même elem_id	0 / 20
Même index → même raw_text (ordre de liste)	20 / 20 (ordre stable)
aria-posinset dans attrs	toujours 0 (non peuplé par cette build OWA)
data-convid (conversation_id) entre appels	stable (même ConversationId Exchange)

Cause

elem_id = id de rendu DOM volatile : OWA/React génère un GUID frais à chaque rendu (format 1da682c2-7ada-f6a1-4cef-83fe279a6bcd, ≠ le base64 du faux positif → l'attribut/la build a changé). Il n'encode ni l'identité du message ni sa position (l'ordre de liste est pourtant stable, mais l'id ne l'est pas ; aria-posinset reste à 0). Inutilisable comme message_id. Le seul identifiant natif stable exposé au niveau ligne est data-convid — mais il est de niveau THREAD (plusieurs mails d'un même fil le partagent), pas par-message.

→ Conclusion : aucun identifiant natif par-message stable n'est disponible via le scraping des attributs de ligne OWA dans l'état actuel. Cohérent avec la conclusion générale « les handles du SPA OWA ne sont pas stables ». Un vrai ItemId Exchange par-message nécessiterait une autre voie (ouverture du message, Graph API, autre attribut DOM) — hors périmètre, non fait.

Décision finale (appliquée le 08/08/2026)

1. message_id reste le hash SHA256 msg_<sha256(subject|date|sender)[:16]> — déterministe et STABLE (le hash n'était pas cassé, juste « non natif »). La branche elem_id est retirée entièrement (pas juste mise en fallback : elem_id n'est jamais falsy, le fallback if not native_id ne se serait jamais déclenché → il aurait toujours servi l'id volatile). Au passage, l'ancien code mort item.get("id") (attribut jamais renvoyé par le bridge) est supprimé aussi.
2. conversation_id conservé : extrait de attrs par regex ciblée r'data-convid=([^|]+)'. NE JAMAIS faire de split('|') global sur attrs : aria-label y est réinjecté en fin de chaîne, texte libre non échappé pouvant contenir des | et des sauts de ligne. data-convid est du base64 sans |, donc [^|]+ est sûr même si le reste est pollué. (Non persisté pour l'instant : la table notes n'a pas de colonne conversation_id — enhancement futur possible.)
3. Fix fiabilité /search conservé : voir section suivante.

Bug annexe corrigé : /search count:0 transitoire

Deux appels /search à < ~10 s d'écart : le 2ᵉ renvoie parfois count:0 (liste virtualisée OWA pas encore stabilisée côté Playwright). Fix dans search_folder : si items est vide de façon inattendue, retry unique après time.sleep(4) avant d'abandonner (simple, pas de backoff).

Garde-fou dédup (vérifié — pas de doublons)

• message_id EST la clé de dédup à l'ingestion (pipeline_processor.py, SELECT id FROM notes WHERE message_id = ?).
• Au moment du chantier : 399 notes, 399 au format msg_<hash>, toutes dans des dossiers de checkpoint done. pending_folders (mcp_server.py) ne resélectionne jamais un dossier done → pas de re-scan → pas de risque de doublon. Les checkpoints non-done (138 error_404, 5 error_409) ont 0 note.
• Fenêtre de risque « code elem_id déployé » : le conteneur a tourné le code dégradé (message_id = id volatile) entre deux rebuilds. Vérifié après coup : 0 note insérée dans cette fenêtre (toujours 399, aucune au format non-hash) → aucun nettoyage nécessaire.
• Caveat documenté : si un jour un checkpoint done est remis manuellement en pending, les anciennes notes ne seraient pas reconnues par la dédup message_id et retomberaient sur le filet vectoriel find_duplicate_in_folder (distance L2 < 0.05 + sujet identique → duplicate_count++).

Voir aussi

• hermes-tt/mail-o365-recherche-scroll-virtualisation.md — virtualisation de la liste OWA (même origine que le count:0 transitoire).
• hermes-tt/mail-o365-hermes-mail-browser-inbox-staleness.md — état de session OWA / staleness.
• hermes-tt/mail-o365-16-dossiers-error-etat-session-owa.md — 502 « Racine du compte introuvable dans le panneau de dossiers » = état OWA dégradé → clear cache + docker restart hermes-mail-browser.

Leçon transférable

Un attribut DOM id=/data-* d'un SPA n'est PAS présumé stable. Le tester sur ≥ 2 rendus réels distincts (appels espacés OU requêtes forçant un re-render), sur plusieurs messages, en appariant par une identité externe stable (raw_text), et vérifier le recouvrement d'ensembles — pas un seul échantillon en position fixe. Ajouté à PROTOCOL-INFRA.md.