Exécutions d'automatisation
Chaque fois qu'un déclencheur se déclenche, Sovrium enregistre une exécution — une ligne capturant la charge utile du déclencheur, le statut et la sortie de chaque étape, et le résultat final. L'API des exécutions vous permet de lister, inspecter, rejouer et annuler les exécutions à des fins de surveillance et de débogage.
API des exécutions
| Méthode et chemin | Objectif |
|---|---|
GET /api/automations/runs |
Liste les exécutions (paginé, filtrable par statut / automatisation). |
GET /api/automations/runs/:id |
Détail de l'exécution incluant les résultats par étape. |
POST /api/automations/runs/:id/replay |
Rejoue une exécution, en reprenant à partir de la première étape en échec. |
POST /api/automations/runs/:id/cancel |
Annule une exécution en attente ou en cours. |
# List failed runs of a specific automation
GET /api/automations/runs?status=failed&automationName=welcome-email
# Replay a failed run
POST /api/automations/runs/550e8400-.../replay
Statuts d'exécution
| Statut | Signification |
|---|---|
pending |
En file d'attente, en attente d'exécution (ou en attente d'un créneau de concurrence). |
running |
En cours d'exécution. |
completed |
Toutes les actions ont réussi. |
completed-with-errors |
Terminée, mais une ou plusieurs étapes ont échoué sous continueOnError. |
failed |
Une action a généré une erreur (déclenche le déclencheur automation-failure + les relances). |
timed-out |
A dépassé le timeout au niveau de l'automatisation ou de l'action. Distinct de failed. |
exhausted |
A échoué après épuisement de toutes les tentatives de relance configurées (dead-letter). |
cancelled |
Annulée manuellement via l'API. |
Statuts d'étape
| Statut | Signification |
|---|---|
running |
En cours d'exécution. |
completed |
A réussi. |
failed |
A généré une erreur. |
skipped |
Non exécutée — par ex. après un arrêt filter/continue ou lors d'une récupération d'échec partiel. |
Rejeu et reprise idempotente
Le rejeu d'une exécution partiellement échouée saute les étapes déjà terminées et reprend à partir de la première étape en échec (reprise idempotente) — les étapes terminées ne sont jamais réexécutées. Le rejeu crée toujours une nouvelle exécution plutôt que de muter l'originale, préservant l'historique d'audit.
Distinguez la durée de l'erreur. Une exécution qui dépasse son timeout est enregistrée comme timed-out, et non failed, afin que les opérateurs puissent distinguer les workflows emballés des véritables erreurs. Une fois les relances épuisées, le statut devient exhausted et le déclencheur automation-failure se déclenche avec l'historique complet des tentatives.
Pages connexes
- Relance et échec — politiques de relance, timeouts, dead-letter, idempotence.
- Déclencheurs — le déclencheur
automation-failurequi réagit aux exécutionsfailed/exhausted. - Vue d'ensemble des automatisations — concurrence et cycle de vie de l'exécution.