runbook: telegram flood-control overflow-split fix + gitea deploy-token (16/07)

_INDEX.md

@@ -33,6 +33,7 @@
 
 | Runbook | Date | Tags |
 |---------|------|------|
+| [Telegram duplication (flood control overflow-split) + Gitea auth (GITEA_DEPLOY_TOKEN)](common/telegram-flood-control-overflow-split-et-gitea-deploy-token.md) | 2026-07-16 | telegram, gitea, git, hermes |
 | [Fragilités de dépendances stack 43 containers](common/fragilites-dependances-stack-20260703.md) | 2026-07-03 | stack, restart, couplage |
 | [Correctifs fragilités appliqués (rla-api, n8n, bifrost-proxy)](common/correctifs-fragilites-application-20260704.md) | 2026-07-04 | correctifs, healthcheck |
 | [Baserow mem_limit 2g](common/baserow-memlimit.md) | 2026-06-29 | baserow, memoire |

common/telegram-flood-control-overflow-split-et-gitea-deploy-token.md

@@ -0,0 +1,76 @@
+# 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.