77 lines
4.3 KiB
Markdown
77 lines
4.3 KiB
Markdown
# 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.
|