hermes-tt: addendum runbook -- fix LIST_ATTACHMENTS_TIMEOUT 20s->35s
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user