hermes-tt: addendum runbook -- fix LIST_ATTACHMENTS_TIMEOUT 20s->35s

2026-08-08 12:01:42 +01:00
parent 3071a5a553
commit 9188fed0ac
1 changed files with 15 additions and 0 deletions
@@ -76,6 +76,21 @@ repart sur un process Edge/CDP propre plutot que de laisser une session tourner
 ---
 **Addendum (meme session, ~1h plus tard)** : le circuit-breaker fonctionnait mais se
 faisait piegier par 3 notes precises du dossier `DR Zone Sud|Gabes` (index 7, 8, 14),
 qui timeoutaient de facon **reproductible** sur `list_attachments` (pas transitoire --
 2 lots de suite, memes 3 notes, meme resultat, y compris apres redemarrage confirme
 healthy du container). Diagnostic direct avec un timeout large (90s) : la reponse arrive
 en ~23,5s et ne fait que 28 octets -- donc pas un volume de PJ important, plutot une
 latence fixe de rendu OWA pour ces messages precis, juste au-dessus de l'ancien seuil de
 20s. Fix : `LIST_ATTACHMENTS_TIMEOUT = 35` (constante dediee, au lieu du `20` en dur).
 Sweep relance apres ce fix : les 3 notes passent du premier coup, aucun `[LIST-FAILED]`
 sur le lot suivant, telechargements de PJ reelles confirmes (PDF recus, tailles coherentes).
 Lecon : un circuit-breaker sur echecs consecutifs protege bien contre la corruption de
 donnees, mais ne distingue pas a lui seul "degradation de session" de "seuil de timeout
 trop serre pour un sous-ensemble reproductible de messages" -- verifier les deux angles
 avant de conclure sur la cause quand le meme point de blocage revient identique.
 ## Verification
 ```bash