4.3 KiB
Telegram duplication (2e occurrence) + Gitea auth cassee (mot de passe rote sans MAJ remotes)
Date : 2026-07-16 Tags : infra, runbook, telegram, gitea, git Instances concernees : hermes-tt, hermes-nyora, hermes-perso (meme image nousresearch/hermes-agent)
Probleme 1 : duplication reponses Telegram (hermes-tt)
Symptome identique a l'incident DNS deja documente (df063f4, "telegram duplication getUpdates
offset + fix DNS agents"), mais cause differente cette fois : le DNS custom (1.1.1.1/9.9.9.9)
etait deja bien applique sur les 3 agents, verifie present et actif.
Cause racine reelle
Fichier /opt/hermes/gateway/platforms/telegram.py, fonction _edit_overflow_split (edition du premier chunk d'un message qui deborde). Quand Telegram declenche son flood control pendant cette edition (telegram.error.RetryAfter), le code ne rattrapait pas l'exception specifiquement : il loggait l'erreur et renvoyait SendResult(success=False) directement. Le gateway interpretait ca comme un echec d'envoi complet et repartait sur un nouveau message au lieu de continuer l'edition
- doublons visibles cote utilisateur, d'autant plus frequents que la reponse est longue/streamee.
Logs confirmant : ERROR gateway.platforms.telegram: [Telegram] Overflow split: first-chunk edit failed: Flood control exceeded. Retry in 9/11 seconds - repete plusieurs fois.
Fix applique
Patch de _edit_overflow_split : la premiere edition tourne desormais dans une boucle avec retry (jusqu'a 3 tentatives), attend le delai indique par retry_after (ou 2s par defaut), puis retente l'edition au lieu d'abandonner. Comportement inchange pour toute autre erreur.
L'image nousresearch/hermes-agent:latest etant un binaire publie (pas de bind-mount du code source), le patch est applique via bind-mount en lecture seule du fichier patche par-dessus celui de l'image :
volumes:
- /volume1/docker/hermes-platform/patches/telegram.py:/opt/hermes/gateway/platforms/telegram.py:ro
Fichier patche versionne dans patches/telegram.py du repo bolbol/hermes-platform. Applique identiquement aux 3 instances (meme image, meme bug potentiel). Verification post-deploy : docker exec CONTAINER grep -c _edit_attempt /opt/hermes/gateway/platforms/telegram.py doit renvoyer un compte superieur a 0 sur les 3.
Piege connexe (perso)
hermes-agent-perso a un override mem_limit: 768m deliberement documente (audit charge NAS
12/07, afdfe69) different du 600m standard des 2 autres instances. Ne jamais harmoniser a 600m
par erreur lors d'un futur merge/nettoyage compose - verifie et confirme lors de ce commit.
Probleme 2 : push Gitea (bolbol) refuse partout - mot de passe deja rote
git push avec le mot de passe historiquement code en dur dans les remotes (2L2u519wgitea) echoue avec Authentication failed, identique sur hermes-platform ET nas-runbooks. Cause : .env (/volume1/docker/hermes-platform/.env, GITEA_PASSWORD) contient deja un mot de passe different et plus recent - la rotation du mot de passe bolbol (famille de secrets 2L2u519w*, tache de securite deja en cours) a ete faite cote Gitea sans mettre a jour les remotes git locaux qui gardaient l'ancien credential en dur dans l'URL.
Fix applique
Remotes des repos hermes-platform et nas-runbooks (clone hermes-nyora/data/workspace/) repointes vers le GITEA_DEPLOY_TOKEN deja present dans .env, jamais utilise jusqu'ici :
git remote set-url origin http://bolbol:GITEA_DEPLOY_TOKEN@192.168.100.33:3232/bolbol/REPO.git
Verifie fonctionnel (git ls-remote + push reussis) sur les 2 repos.
A faire (Nabil)
- Revoquer manuellement (Gitea UI > Settings > Applications) le token temporaire nas-push-20260716 cree pendant l'investigation avant de trouver le GITEA_DEPLOY_TOKEN existant - plus necessaire, doublon.
- Generaliser l'usage de GITEA_DEPLOY_TOKEN sur les autres remotes locaux (rla-api, gsparc-mezzouna, etc.) qui utilisent probablement encore l'ancien mot de passe en dur et echoueront au premier push.
Note : clone nas-runbooks stale (hermes-nyora/data/workspace/nas-runbooks)
Ce clone local etait environ 60 commits derriere origin/main (jamais synchronise depuis longtemps). Les fichiers non commites qu'il contenait se sont averes identiques ou deja consolides dans des versions plus recentes existant sur origin (verifie par diff). Rien n'a ete perdu. Le clone a ete reset (git reset --hard origin/main) pour redevenir propre et utilisable.