Aller au contenu

Déterminisme et contrôle

Que se passe-t-il si le serveur tombe au milieu d'un envoi ?

C'est la panne qui fait le plus de dégâts en production : le processus a envoyé un mail, le serveur tombe avant d'avoir noté qu'il l'a fait, et la reprise l'envoie une seconde fois. EchoBrain journalise l'intention avant l'appel, avec une clé d'idempotence stable, et vérifie l'état réel avant toute reprise.

Mise à jour le

La séquence, dans l'ordre :

  1. Avant l'appel, une intention est écrite dans le journal, avec une clé calculée à partir de l'exécution, de l'étape, du numéro de tentative et de l'empreinte des entrées. La même situation redonne toujours la même clé.
  2. La clé est portée jusqu'au système distant — en-tête d'idempotence, identifiant de message déterministe selon le connecteur.
  3. Après l'appel, une confirmation est écrite.
  4. Une intention sans confirmation est réconciliée : le système va vérifier si l'effet a eu lieu.

Trois comportements de connecteurs, déclarés et vérifiés :

  • idempotence native — la reprise automatique est sûre ;
  • réconciliable — la reprise est sûre après vérification ;
  • aucune — la reprise automatique est interdite : une tâche s'ouvre pour un humain.

Un connecteur qui se déclarerait à tort dans une classe plus permissive ne passe pas la suite de conformité.

Le sujet en entier : déterminisme