Skip to main content
View as Markdown

Gestion des relances et des échecs

Les automatisations sont résilientes par configuration : relancez les échecs transitoires avec un backoff, encadrez les étapes emballées avec des timeouts, récupérez les exécutions partiellement échouées de manière idempotente, et acheminez les exécutions épuisées vers un gestionnaire d'échec.

Politique de relance

Un bloc retry peut être défini au niveau de l'automatisation (exécution entière) ou au niveau de l'action (étape unique).

Propriété Description
maxAttempts Nombre maximal de tentatives de relance (1–10). Requis.
delayMs Délai de base entre les relances en ms (100–60000, par défaut 1000).
strategy fixed (délai constant, par défaut) ou exponential (backoff croissant). 
automations:
  - name: sync-inventory
    trigger: { type: cron, expression: '0 * * * *' }
    retry: { maxAttempts: 5, delayMs: 2000, strategy: exponential }
    actions:
      - name: pull
        type: http
        operator: get
        props: { url: $env.INVENTORY_API, expectedStatus: [200] }
        retry: { maxAttempts: 3, strategy: fixed } # per-action override

Timeouts

Deux portées de timeout indépendantes :

Portée Où Effet
Automatisation automation.timeout (1000–900000) Plafonne la durée totale de l'exécution. À l'expiration, l'exécution est marquée timed-out.
Action (uniforme) action.timeout (1000–900000) Plafonne une étape ; retry/continueOnError s'appliquent toujours.
Action (gestionnaire) action.props.timeout Encadrement interne par type (par ex. http, code, automation/call).

Une exécution timed-out est distincte de failed afin que les opérateurs puissent distinguer une durée emballée des erreurs.

Continuer en cas d'erreur

Définissez continueOnError: true sur une action afin que son échec n'interrompe pas l'exécution. Les actions suivantes s'exécutent toujours et l'exécution se termine en completed-with-errors.

- name: bestEffortLog
  type: analytics
  operator: track
  continueOnError: true
  props: { event: order.created, properties: { id: '{{trigger.data.id}}' } }

Dead-letter et épuisement

Lorsqu'une exécution échoue après avoir épuisé tous les maxAttempts configurés, elle passe au statut exhausted (dead-letter). Chaque tentative est enregistrée avec un horodatage, un message d'erreur et une trace de pile. Le déclencheur automation-failure se déclenche après l'épuisement, transmettant au gestionnaire d'échec l'historique complet des tentatives — permettant une gestion d'échec centralisée sans configuration de notification par automatisation.

Récupération d'échec partiel et idempotence

Lorsqu'une exécution échoue au milieu du pipeline, les étapes terminées affichent completed, l'étape en échec affiche failed, et les étapes en aval affichent skipped. Le rejeu de l'exécution reprend à partir de l'étape en échec, en sautant les étapes déjà terminées (reprise idempotente). Le rejeu crée toujours une nouvelle exécution, sans jamais muter l'originale.

Pages connexes