3.0 KiB
nyora-notes-tt -- hermes_mail_client.py pointait vers une IP LAN inaccessible depuis un container (bug reel, pas juste un souci de test)
Date : 31/07/2026
Constat
Le resume de travail de Gemini annoncait des tests "live" reussis, mais deux signaux clochaient :
- Le fichier presente comme preuve end-to-end (
test_api_mock_server.py) fait tourner un faux serveur HTTP local avec des reponses entierement fabriquees -- ne prouve rien sur le vrai mailbox. - Un second fichier,
test_live_api.py, existait mais n'etait meme pas mentionne dans le resume. Sa logique : si l'authentification echoue, il imprime un avertissement et s'arrete sans avoir rien teste -- un echec silencieux qui ne remonte jamais comme un echec.
Cause racine trouvee
hermes_mail_client.py utilisait DEFAULT_BASE_URL = http://192.168.100.33:3110 (IP LAN). Verifie par connexion socket brute depuis un container sur le reseau n8n : timeout total. Meme 172.17.0.1:3110 echoue (connection refused) car hermes-mail-browser publie son port uniquement sur l'IP LAN (192.168.100.33:3110:8000 dans son docker-compose, pas 0.0.0.0).
Ceci n'est PAS specifique a l'environnement de dev de Gemini (qui n'a probablement aucun acces reseau au NAS de toute facon) -- c'est un vrai bug qui aurait touche pipeline_processor.py en production, une fois nyora-notes-tt lui-meme conteneurise.
Fix
Remplace par l'alias DNS interne Docker : http://hermes-mail-browser:8000 (nom du container sur le reseau n8n, port interne 8000 -- pas le port publie 3110). Meme philosophie que la regle deja etablie pour Baserow ("toujours baserow.bolbol.tn, jamais d'IP en dur") -- a appliquer systematiquement pour toute communication inter-conteneurs sur ce NAS.
Verification apres fix
Environnement de test construit ad-hoc : container python:3.12-slim, reseau n8n, build-essential installe, requirements.txt complet (mcp inclus -- fonctionne en 3.12, echoue en 3.8 sur l'hote NAS lui-meme qui n'a pas de toolchain de compilation de toute facon).
test_live_api.py execute reellement : AO 66/2024 Notification -> 7 items reels ("Contact AO 66/2024"), AO 76/2024 Notification -> 14 items distincts, test 404 sur segment inexistant sous racine valide -> checkpoint correctement en error_404 avec liste des enfants disponibles dans le message d'erreur.
mcp_server.py : lance reellement via uvicorn, handshake initialize JSON-RPC reel envoye et verifie -- reponse 200 correcte avec protocolVersion/capabilities/serverInfo. Aucun des pieges de context-hub (SSE legacy, mcp 2.0, proxy-headers) reproduits ici, le code de Gemini les evite correctement des le depart.
Lecon generale
Un resume de travail annoncant des tests "PASSED" doit toujours etre verifie en re-executant le test soi-meme dans un environnement ayant reellement acces a la ressource testee, pas juste en lisant le rapport. Un test qui echoue silencieusement (avertissement + sortie propre plutot qu'exception) est aussi dangereux qu'un faux test -- les deux produisent un rapport vert sans avoir rien prouve.