Exécutions

Une exécution est un passage d'une version de workflow, lancé par un événement : un mail qui correspond, une heure planifiée, un appel de webhook, un appel depuis un autre workflow, un changement chez une intégration, un lancement manuel ou un essai. Elle enregistre tout ce que ce passage a fait, nœud par nœud, pour pouvoir répondre à la question « qu'est-ce que l'automatisation a fait de ce mail, et pourquoi ? ».

Une exécution se compose d'étapes : une étape par nœud atteint. Chaque étape est écrite en base avant et après l'exécution de son nœud. Rien n'est conservé uniquement en mémoire : c'est ce qui permet à une exécution de survivre à un redémarrage, d'attendre des jours, et d'être examinée après coup.

Comment une exécution démarre

Chaque déclencheur crée ses exécutions à sa façon, et chacun se protège des doublons :

Déclencheur	Une exécution par	Doublons
Mail reçu	mail correspondant et version publiée	Le même mail livré deux fois (par exemple par une notification push et par une vérification périodique) ne crée qu'une exécution. Publier une nouvelle version permet de traiter à nouveau un mail déjà vu par la version précédente.
Planification	occurrence prévue	Une occurrence ne tire qu'une fois, même avec plusieurs serveurs.
Webhook reçu	requête reçue	Deux appels sont deux événements : rien n'est fusionné. Pour une intégration qui envoie un identifiant de livraison, une livraison renvoyée par le fournisseur est reconnue et absorbée.
Changement chez une intégration (sondage, par exemple Airtable)	élément modifié	Un élément déjà traité ne l'est pas une seconde fois après un incident.
Appelé par un workflow	appel depuis le nœud Appeler un workflow	Une exécution enfant par étape appelante, même si cette étape fait une nouvelle tentative.
Lancement manuel	clic	Aucune déduplication : lancer deux fois un workflow sur le même mail est un geste voulu, qui produit deux exécutions.
Essai depuis l'éditeur	essai	Chaque essai est une nouvelle exécution, sans effet réel (voir Essais).

Un mail qui correspond à plusieurs workflows lance une exécution par workflow, ou seulement certaines, selon le réglage « Si plusieurs workflows correspondent » du déclencheur mail (voir Déclencheurs).

Une exécution fait tourner la version du workflow publiée au moment de sa création, et en garde la référence. Modifier le brouillon ou republier ne change jamais une exécution déjà commencée. Seules les branches du déclencheur qui a lancé l'exécution tournent : un workflow qui écoute aussi les mails ne fait pas tourner sa branche mail parce qu'une heure planifiée est arrivée.

Les statuts d'une exécution

Statut	Libellé	Signification
queued	En file	Créée, aucune étape n'a encore démarré.
running	En cours	Au moins une étape est prête ou en cours.
waiting	En attente	Plus rien ne tourne : les étapes restantes attendent un événement (une date, une approbation, un workflow appelé, des itérations de boucle).
succeeded	Réussie	Chaque branche est allée au bout sans échec définitif.
failed	En échec	Au moins une étape a échoué définitivement.
cancelled	Annulée	Un signal a mis fin à l'exécution pendant qu'elle attendait.

succeeded, failed et cancelled sont définitifs : plus rien n'est planifié ensuite.

Les statuts d'une étape

Statut	Libellé	Signification
queued	En file	Le nœud est prêt à tourner et attend un processus disponible.
running	En cours	Le nœud tourne, ou a échoué temporairement et va être retenté.
waiting	En attente	Le nœud a demandé à attendre (voir Attente et reprise). Aucun processus ne s'en occupe.
succeeded	Réussie	Le nœud s'est terminé et a choisi une sortie.
failed	En échec	Le nœud a échoué définitivement.
skipped	Ignorée	Le nœud n'était pas sur le chemin emprunté par cette exécution.

La vue d'exécution distingue aussi deux variantes d'une étape réussie :

• Épinglée (non exécutée) : pendant un essai, le nœud porte des données épinglées. Il n'a pas tourné ; sa sortie épinglée a alimenté les nœuds suivants.
• Traversé (désactivé) : le nœud est désactivé. Il n'a pas tourné, n'a rien appelé, et les données sont passées directement aux nœuds suivants.

Branches et étapes ignorées

Après chaque étape, Mankomail détermine quels nœuds peuvent tourner ensuite. La règle :

Un nœud tourne quand toutes ses connexions entrantes sont réglées et qu'au moins une est vive. Une connexion est réglée quand le nœud dont elle part s'est terminé (réussi, échoué ou ignoré). Elle est vive quand ce nœud a réussi et a choisi la sortie d'où part la connexion.

Conséquences :

• Une Condition (Si) qui prend la sortie « vrai » rend ignorés les nœuds branchés sur « faux », et tout ce qui ne dépend que d'eux l'est à son tour.
• Un nœud alimenté par deux branches exclusives (par exemple la sortie « vrai » d'une condition et une catégorie de Catégoriser) tourne dès que l'une d'elles arrive. Il n'attend pas les deux.
• Un nœud qui ne rend aucune sortie (il termine sa branche sans erreur, comme Catégoriser réglé pour s'arrêter quand aucune catégorie ne convient) règle ses connexions sans les rendre vives.
• Les nœuds du corps pour chaque d'une Boucle apparaissent ignorés dans l'exécution qui contient la boucle : ils ont tourné dans les itérations, qui sont des exécutions à part.
• Quand plusieurs nœuds sont prêts en même temps, ils tournent en parallèle.

Quand une étape échoue

Une étape qui échoue définitivement fait terminer l'exécution en failed. Les autres branches déjà en cours vont d'abord jusqu'au bout ; les étapes qui attendaient encore un événement sur une autre branche sont alors abandonnées, pour que personne n'approuve un envoi appartenant à une exécution en échec.

Chaque nœud peut être réglé pour continuer, ou pour suivre une sortie Erreur, au lieu d'arrêter l'exécution. Ces réglages, les codes d'erreur et la façon de rejouer une exécution en échec sont décrits dans Gestion des erreurs et rejeu.

Les nouvelles tentatives automatiques

Les erreurs sont classées en deux familles :

• Temporaires (panne réseau, fournisseur indisponible, délai dépassé) : l'étape est retentée automatiquement.
• Définitives (réglage invalide, boîte manquante, refus définitif du fournisseur) : l'étape échoue immédiatement. Réessayer échouerait de la même façon.

Une erreur qui ne dit pas à quelle famille elle appartient est traitée comme temporaire.

Par défaut, une étape dispose de 5 tentatives. L'attente avant chaque nouvelle tentative double, en partant de 2 secondes, avec une variation aléatoire de ±20 % pour que de nombreuses exécutions touchées par le même incident ne réessaient pas au même instant :

Après l'échec de la tentative	Attente avant la suivante
1	environ 2 s
2	environ 4 s
3	environ 8 s
4	environ 16 s
5	aucune : l'étape échoue définitivement

Pendant les nouvelles tentatives, l'étape reste En cours et son compteur de tentatives augmente (affiché « tentative 2 », « tentative 3 »… dans la vue d'exécution). Quand un fournisseur répond qu'un quota est atteint, l'étape est reportée jusqu'au moment indiqué par le fournisseur, sans consommer de tentative.

La façon dont les nouvelles tentatives se combinent avec les réglages d'échec d'un nœud est décrite dans Gestion des erreurs et rejeu.

Les effets externes ne sont jamais doublés

Une étape peut tourner plus d'une fois : après une nouvelle tentative, après la panne d'un processus, ou après un redémarrage. Mankomail rend ce cas inoffensif :

• Une étape déjà réglée n'est jamais exécutée à nouveau.
• Chaque étape reçoit une clé d'idempotence stable, dérivée de l'exécution et du nœud, la même à chaque tentative.
• Les mails partent par une file d'envoi indexée sur cette étape : une nouvelle tentative de l'étape retrouve son envoi déjà enregistré et n'envoie pas un second mail.
• Les nœuds qui appellent un service externe transmettent la clé à ce service quand il sait l'utiliser. Quand le fournisseur n'a pas ce mécanisme, la page du nœud le signale et, si possible, propose une protection (par exemple la Colonne de dédoublonnage de Sheets — ajouter une ligne). Avec le nœud générique Requête HTTP, préférez des points d'accès idempotents pour les écritures.

Un lancement manuel ou un rejeu est une nouvelle exécution, avec de nouvelles clés : lancer volontairement deux fois le même mail envoie bien deux fois.

Attente et reprise

Quatre nœuds peuvent faire attendre une étape sans rien bloquer :

Nœud	Attend
Attendre	une date ou un délai, éventuellement écourté par une réponse dans le fil ou par un signal
Approbation	la décision d'une personne (voir Relecture et approbations)
Appeler un workflow	la fin du workflow appelé
Boucle	la fin de toutes ses itérations

Le nœud ne dort pas. Il enregistre ce qu'il attend, l'étape passe En attente, et aucun processus ne s'en occupe. Quand plus rien d'autre ne tourne, l'exécution passe elle aussi En attente. Quand l'événement arrive (la date est atteinte, quelqu'un approuve, l'exécution enfant se termine), l'étape reprend, emprunte la sortie qui correspond à l'événement, et l'exécution continue. Une exécution en attente ne coûte rien pendant qu'elle attend, qu'elle attende une minute ou un an.

Une attente longue est plafonnée par l'instance (730 jours par défaut, WAIT_MAX_DAYS, voir Variables d'environnement).

Annuler une exécution en attente. Le nœud Émettre un signal, avec « Ce que le signal fait » réglé sur Annuler les exécutions en attente, met fin à toutes les exécutions qui attendent sur la même clé de corrélation. Elles passent Annulée et rien de ce qui suit l'attente ne tourne : la relance ne part jamais.

Durabilité

Chaque changement d'état est écrit en base avant que le travail qu'il décrit ne soit fait :

• les étapes à exécuter sont enregistrées, puis les tâches qui les exécutent sont mises en file ;
• un processus qui s'arrête au milieu d'une étape perd sa réservation au bout d'un moment, et un autre processus reprend l'étape ;
• une étape laissée prête par un incident est retrouvée et exécutée ;
• les attentes reposent sur des échéances enregistrées durablement, pas sur des minuteurs : un redéploiement ou un redémarrage ne perd rien, même pendant une attente d'un an ;
• les données produites par chaque étape sont conservées avec l'étape.

Redémarrer ou mettre à jour le serveur ne perd donc jamais une exécution. Le pire cas est une étape exécutée une seconde fois, ce que la clé d'idempotence ci-dessus rend inoffensif.

Les données d'étape

Pour chaque étape, l'exécution enregistre :

• son statut, son numéro de tentative, ses heures de début et de fin, et sa durée ;
• la sortie empruntée (le nom du port), ou aucune si la branche s'arrête là ;
• les données produites : les valeurs que les nœuds suivants lisent sous data.<nœud>.… (voir Données et expressions). La plupart des nœuds y ajoutent un summary, une phrase lisible qui dit par exemple ce qui a été trouvé ou envoyé, rédigée dans la langue du membre propriétaire du workflow ;
• ses effets : ce que le nœud a fait à l'extérieur (un mail envoyé, un fichier déposé, un modèle appelé), chacun marqué réel ou d’essai ;
• l'erreur en cas d'échec : un code, un message technique et le nœud concerné.

Les données jusqu'à 32 Kio sont renvoyées avec l'étape. Au-delà, elles sont stockées à part : les nœuds suivants les lisent toujours en entier, mais la vue d'exécution affiche « La sortie de ce nœud était trop grosse pour être renvoyée avec l’étape. ».

Mettre un workflow en pause et couper les envois

Deux interrupteurs arrêtent l'activité sans rien supprimer :

• Mettre en pause un workflow publié : aucune nouvelle exécution ne démarre ; celles en cours se terminent, et les étapes en attente continuent d'attendre. Reprendre fait repartir immédiatement les nouvelles exécutions. Un brouillon ne peut pas être mis en pause, puisqu'il ne tourne pas.
• Couper les envois dans Admin → Envois : les envois réels (réponses, transferts, nouveaux messages) sont retenus pour toute l'organisation, tandis que le reste continue de tourner. À Rouvrir les envois, ce qui était retenu repart ; rien n'est perdu, rien n'est envoyé deux fois. Une instance peut aussi être coupée par sa configuration (SEND_ENABLED) ; l'interrupteur de l'organisation ne peut pas la rouvrir. Voir Gouvernance.

Consulter les exécutions

• Onglet Exécutions d'un workflow, à côté de Éditeur : la liste de ses exécutions, de la plus récente à la plus ancienne, avec leur statut et leur déclencheur (Planifiée, Webhook, Appelée, Manuelle…). Filtrez par statut (« Tous les statuts ») et par nature (« Essais et réelles », « Essais seulement », « Réelles seulement »). Choisissez une exécution pour la revoir sur le canvas : chaque nœud y affiche son statut. Ouvrir en plein écran ouvre la vue détaillée.
• Page Exécution : le résumé (« Simulée » pour un essai, ou « Réelle — les effets sont partis »), les heures Demandée / Démarrée / Terminée, le Mail concerné avec Ouvrir le fil, puis les Étapes, chacune avec son statut, sa tentative, ses effets et Voir les données. Une étape de boucle liste ses Itérations (« 12 itérations · 11 réussies · 1 en échec ») et ouvre chacune d'elles. Fichiers produits liste les documents que l'exécution a récupérés ou fabriqués. Un rejeu renvoie à l'exécution d'origine.
• Pourquoi ? sur un mail, dans le webmail : les workflows qui ont tourné sur ce mail et leurs exécutions.
• Page Activité : À traiter liste les décisions qu'attendent vos workflows et les exécutions en échec que personne n'a encore regardées ; Attentes liste ce qui est en attente ; Mails reçus montre les exécutions des dernières 24 heures. Un bandeau signale les exécutions en échec des dernières 24 heures jusqu'à ce que vous les marquiez comme vues.

Conservation

Les exécutions réelles terminées, avec leurs étapes et leurs données, sont supprimées 180 jours après leur création. Les essais sont supprimés au bout de 7 jours par défaut, réglables avec SIMULATED_EXECUTIONS_RETENTION_DAYS (de 1 à 365). Les exécutions réelles encore en cours ou en attente ne sont jamais supprimées par la conservation.

Pages liées

• Gestion des erreurs et rejeu
• Données et expressions
• Essais
• Déclencheurs
• Relecture et approbations