From 9188fed0aca8de1ac838eed072f54b414bbc5f3d Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 7 Aug 2026 10:50:38 +0100 Subject: [PATCH] hermes-tt: addendum runbook -- fix LIST_ATTACHMENTS_TIMEOUT 20s->35s --- .../download-attachments-phase1-bug-timeout.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/hermes-tt/download-attachments-phase1-bug-timeout.md b/hermes-tt/download-attachments-phase1-bug-timeout.md index 0a56a1d..f80d9de 100644 --- a/hermes-tt/download-attachments-phase1-bug-timeout.md +++ b/hermes-tt/download-attachments-phase1-bug-timeout.md @@ -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