Observabilité des erreurs (swing positions)
1. Contrat errorCode
- Chaque activité d’échec exchange pertinente inclut
context.errorCode(voir error-map.json). - Les logs structurés (
logError) incluent les mêmes champs :errorCode,positionId,exchangePair,activityType,spec:swing-positions/observability-errors.
2. errorFlags sur swingPosition
En plus des flags d’intégrité existants (RELATIVE_AMOUNT_INCONSISTENT, TP2_BEFORE_TP1, etc.) :
| Flag | Condition |
|---|---|
| REPEATED_TP_EXCHANGE_ERROR | Au moins 3 activités cumulées de type TP1_EXCHANGE_ERROR ou TP2_EXCHANGE_ERROR. |
| TP_EXCHANGE_ERROR_STALLED | Au moins 10 de ces mêmes activités (boucle de retry). |
activity.
3. BetterStack (recommandations)
Configurer des vues / alertes sur les champs JSON des logs applicatifs (adapter au format exact de ton shipper) :- Critique :
errorFlagscontientTP_EXCHANGE_ERROR_STALLEDouerrorCoderépété > N fois / 15 min pour un mêmepositionId. - Warning :
errorCode=EXCHANGE_MIN_AMOUNTou flagREPEATED_TP_EXCHANGE_ERROR. - Réduction de bruit : ne pas alerter sur le même
positionId+ mêmeerrorCodeplus d’une fois par heure sans variation (déduplication côté BetterStack si disponible).
4. Audits MongoDB (exemples)
À exécuter dans Compass,mongosh ou via MCP (lecture seule).
Positions RUNNING avec erreurs TP répétées (aperçu) :
5. Fichiers liés
- error-map.json — registre machine-lisible.
- etat-running.md — diagramme XState et états d’erreur RUNNING.