Corriger un projecteur

Projecteur cassé

Un projecteur cassé ne va plus mettre à jour sa projection. Le read model ne va donc plus être mis à jour et l'application va potentiellement (sûrement) afficher des informations périmées. La bonne nouvelle est que le write model ne peut pas être corrompu par des commandes qui seraient envoyées.
Par exemple, après une confirmation de demande, si l'interface (qui utilise le read model) croit que la demande est toujours déposée, elle va proposer à l'utilisateur de la confirmer. Une nouvelle commande de confirmation pourra donc être envoyée, mais elle sera ignorée par le write model qui lui est à jour.

Malgré cette sécurité, il est important de corriger le plus vite possible. Une fois le correctif déployé, il faudra amorcer les projecteurs pour marquer le projecteur cassé comme bloqué et lui faire rejouer les évènements manquants.

$ python -m pip install listsem
$ listsem projecteurs amorcer

Projectionniste interrompu

Si, par exemple, il y a eu un problème avec l'envoi d'email. Cela est déjà arrivé en production ! Le projecteur n'était pas cassé, mais il ne consommait plus les évènements depuis plusieurs semaines. Pour corriger le problème, le projectionniste a été arrêté puis re-démarré.

…

Toutes les notifications en retard des semaines d'arrêt ont été envoyées ! Ce qui n'était pas souhaité ! Il aurait mieux valu ne pas les envoyer puis attendre que la tâche d'envoi des rappels fasse sont travail.

Pour éviter ce genre de problème (qui devrait être très rare), il faut bloquer les projecteurs problématiques. Il faudra ensuite les ré-amorcer. À l'amorçage, les projecteurs héritant de RunFromNow (l'envoi de notifications) vont sauter les évènements non consommés, alors que les projecteurs héritant de RunFromBeginning (les projections classiques) vont jouer tous les évènements qu'ils auront en retard.

$ listsem projecteurs bloquer <NOM_DU_PROJECTEUR>