Des exécutions dignes de confiance

Personne ne remarque une automatisation avant qu'elle n'envoie quelque chose deux fois

Ensuite, tout le monde le remarque. Les quatre mécanismes présentés sur cette page existent parce que les défaillances de ce type de logiciel sont toujours les mêmes quatre défaillances, et toutes sont évitables par conception plutôt que par vigilance.

Simulez avant de publier

Poussez un enregistrement réel dans un workflow désactivé, et lisez exactement ce qui se serait passé : le chemin emprunté, chaque valeur à chaque étape, la formulation de chaque message, et la requête qui aurait été envoyée à chaque système externe.

Rien ne sort de l'édifice. Aucun e-mail n'est envoyé, aucune facture émise, aucun prélèvement tenté, aucune ligne écrite. Les appels externes sont enregistrés comme intentions, avec la charge utile qui aurait été envoyée, afin que vous puissiez vérifier si le mappage est correct avant qu'il ne devienne le problème de quelqu'un.

Les simulations sont la façon de répondre à la question qui empêche les gens d'activer une automatisation : que fera-t-elle concrètement ?

Simulation · commande 88 214Rien n'est envoyé

1Valider l'adresseCorrespondance trouvée. 6 champs auraient été écrits.
?ConditionCommande de plus de 1 000 zł ? Non — 289,00 zł. Chemin court emprunté.
3FactureEnverrait une requête POST au système de facturation. Charge utile affichée intégralement.
!Détecté iciTaux de TVA mappé depuis le mauvais champ. Trouvé dans une simulation plutôt que dans la boîte mail d'un comptable.

Envoyé : rienFacturé : rien

Une exécution suit la version sur laquelle elle est entrée

Publier une modification d'un workflow ne touche pas les exécutions déjà en cours. Chaque exécution est attachée à la version sur laquelle elle a démarré et termine cette version, aussi longtemps que cela prend et aussi profondément que vous réécrivez le workflow entre-temps.

Ainsi, vous pouvez restructurer un workflow pendant que dix mille personnes en sont à mi-chemin, et chacune d'elles termine le parcours qui lui avait été promis. L'alternative — la conception où tout le chemin aval est matérialisé à l'entrée — est la raison pour laquelle modifier une automatisation en production paraît dangereux dans la plupart des outils. Ici, c'est banal.

Les nouvelles exécutions obtiennent la nouvelle version dès l'instant où vous publiez. La version sur laquelle se trouve une exécution est inscrite sur celle-ci, si bien qu'une question sur le comportement en mars a une réponse en septembre.

Modification en productionv4 → v5

1Avant2 918 exécutions en cours, toutes sur v4. Certaines dans une attente de deux jours.
2Publier v511:40Deux étapes réordonnées, un message réécrit.
3AprèsCes 2 918 terminent en v4. Tout ce qui démarre à partir de 11h40 s'exécute en v5.
§Personnene reçoit la moitié d'un workflow et la moitié d'un autre.

Version enregistrée sur chaque exécutionAnciennes versions conservées

Des relances qui ne peuvent pas envoyer en double

Une étape est une fonction pure de ses entrées, et ses effets sont validés ensemble avec l'avancement de l'exécution vers l'étape suivante. Il n'existe aucune fenêtre pendant laquelle le message est parti sans que l'exécution le sache.

C'est tout le secret, et c'est une propriété structurelle plutôt qu'une promesse. Un worker tué au milieu d'une étape — un déploiement, un plantage, une machine qui disparaît — laisse l'exécution exactement où elle en était. Un autre worker la récupère et réexécute l'étape. Comme l'effet et l'avancement sont validés comme un seul, soit les deux se sont produits, soit aucun des deux.

Les appels sortants vers des systèmes qui prennent en charge les clés d'idempotence en portent une, dérivée de l'exécution et de l'étape, afin que l'autre partie puisse également reconnaître le doublon.

Worker tué en cours d'envoiRécupéré

1L'étape 5 commence09:14:06Envoyez l'avis d'expédition.
✕Le worker meurt09:14:07Déploiement. Rien n'avait été validé.
2Pris en charge09:14:31Un autre worker constate que l'exécution est toujours à l'étape 5.
✓Envoyé une seule fois09:14:32Le client a reçu un seul e-mail, pas deux.

Les effets sont validés avec l'avancementClé d'idempotence par exécution et par étape

Un journal écrit pour être lu par une personne

Chaque exécution, chaque étape, la branche empruntée et la valeur qui l'a décidée. Les durées par étape. La requête et la réponse de chaque appel externe, avec les identifiants masqués. La version sur laquelle tournait l'exécution. Où une exécution attend, et jusqu'à quand.

Quand quelqu'un demande ce qu'il est advenu de la commande passée le quatorze, il y a une réponse, et la trouver prend une minute plutôt qu'un après-midi à recouper les journaux de trois systèmes.

Les exécutions en échec se regroupent au même endroit, avec la raison classée, de sorte que « quarante-et-une échecs pendant la nuit » se résout en « un fournisseur a renvoyé 503 pendant neuf minutes » plutôt qu'en quarante-et-une enquêtes distinctes.

Pendant la nuit, groupés41 échecs

1Une seule causeL'API du fournisseur a renvoyé 503 entre 02:41 et 02:50.
2Ce qui s'est passéLes 41 ont été relancées ; 39 ont réussi à la deuxième tentative.
3RestantesDeux se sont arrêtées et attendent une personne. Les deux sont listées avec la ligne en échec.
§Pas quarante-et-uneenquêtes. Une seule, et une décision sur deux enregistrements.

Identifiants masquésVersion enregistrée

Ce que nous ne prétendons pas

Nous ne publions pas de chiffre de disponibilité sur une page marketing, car un nombre sans fenêtre de mesure ni définition de « disponible » n'est qu'un ornement. Si vous en avez besoin contractuellement, demandez et nous parlerons de ce à quoi nous pouvons réellement nous engager.

Nous ne pouvons pas non plus rendre fiable l'API de quelqu'un d'autre. Si un fournisseur est en panne, un workflow qui en dépend attend, relance et finit par s'arrêter avec une raison claire. Ce que nous pouvons promettre, c'est que l'échec est visible, qu'il ne corrompt rien, et que la reprise n'envoie pas le message une seconde fois.

Sur les attentes : une exécution qui attend pendant deux jours est un wake_at sur l'exécution, pas une tâche posée dans une file. C'est pourquoi un workflow peut conserver cent mille exécutions en attente de trois semaines sans que cela ne coûte quoi que ce soit, et pourquoi le nombre d'exécutions actuellement en attente n'est pas quelque chose auquel vous devez penser.