3.7 KiB
hermes-mail-browser -- /search ne filtre pas par date reelle de reception
Date : 30/07/2026 Contexte : tentative d estimation du volume de mails TT depuis 2024 (projet nyora-notes-TT / RAG personnel mail).
Constat
Le endpoint /search?q=... de hermes-mail-browser fait du matching texte brut sur la requete OWA,
pas un filtre sur la date reelle de reception. Test : q=received:2024 a retourne des mails recus
en 2025 (12/08/2025, 22/09/2025, 26/02/2025, 31/01/2025) simplement parce que 2024 apparaissait
dans le sujet (numeros d AO type AO 76/2024, N066/2024). OWA traite received:2024 comme un
terme de recherche libre dans ce contexte, pas comme un operateur de plage de dates fiable via cette API.
Autre limite observee
/folders retourne count:0, folders:[] ou time out -- coherent avec le bug de staleness deja documente le 24/07 (liste virtualisee OWA non remontee sans navigation fraiche forcee). Pas de comptage fiable par dossier via cette route en l etat.
Cout reel
Chaque appel /search prend ~35-40s pour 5 resultats (automatisation navigateur reelle sur OWA, pas une API rapide). Inadapte a une iteration/pagination pour estimer un volume total -- risque de degrader ou perdre la session authentifiee live (auth manuelle noVNC, MFA).
Recommandation
Pour un comptage de volume par dossier/periode : lire directement le compteur natif OWA (volet dossiers, ou Filtrer > par date) via noVNC (port 8810) -- 30 secondes, fiable, zero risque sur la session. Ne pas utiliser /search avec un mot-cle annee en attendant un filtre de date reel.
A faire si le filtre date devient necessaire
Verifier si OWA supporte un operateur de date fiable dans son moteur de recherche natif (ex. received>=01/01/2024) teste directement dans l UI avant de l attendre de cette API generique.
MAJ 30/07/2026 -- cause racine trouvee et corrigee (partiellement) : DNS Pi-hole
En creusant la question de Nabil ("pourquoi /folders ne marche pas, est-ce a regler tout de suite"), inspection des logs container : SmartScreenDnsResolver timeout sur outlook.office.com et outlook.cloud.microsoft, avec en consequence un /inbox qui remontait carrement en 502 Bad Gateway par intermittence -- pas seulement /folders, un vrai bug de prod deja actif avant le projet RAG.
Cause : hermes-mail-browser tournait sans override DNS, donc resolution via Pi-hole (meme classe de bug que la duplication Telegram corrigee le 09/07 sur hermes-agent-*).
Fix applique : ajout dns: [1.1.1.1, 9.9.9.9] dans docker-compose.yml, recreate du container.
Verifie : resolution DNS immediate (getent hosts en <1s, avant : timeout), /auth/status repond en
22ms (avant : dans la chaine de timeouts), session browser persistee sans besoin de re-auth noVNC.
Ce qui reste casse malgre le fix DNS : /folders. Comportement desormais flaky et non lie au
DNS -- soit timeout a 30s+, soit reponse rapide (~3s) mais vide (count:0). C est un bug cote
implementation (selecteur/logique de lecture du volet dossiers OWA, probablement arbre virtualise/
replie non deplie par le scraper), pas un probleme reseau. A traiter comme un vrai chantier de dev
sur l app hermes-mail-browser, pas un quick fix -- necessite d inspecter le code Playwright de la
route /folders.
Confirmation /inbox : ne retourne QUE des items de mail (raw_text, aria_label) -- zero info de dossier/sous-dossier. Ne lit que le volet liste des messages, jamais le volet dossiers.
A faire cote versioning : ce changement compose vit sur /volume1/docker/hermes-mail-browser, non versionne en Git depuis le NAS (pas de .git ici, conforme a la regle Git absent du NAS). Nabil doit committer/push depuis son Mac (/Volumes/docker) pour capitaliser ce fix dans l historique.