Détecter les applications qui plantent juste après la publication

Le 25 septembre, trois publications ont été marquées comme réussies alors que l'API de l'application plantait quelques secondes après chaque démarrage. Comme elles avaient « réussi », aucune restauration n'a été lancée ; une vérification en arrière-plan les a déclarées en échec quelques minutes plus tard, et tout le site a renvoyé une erreur 404. Le contrôle de santé comptait les plantages dans la liste d'événements de la plateforme d'hébergement, qui ne conserve que les cinq derniers événements par machine : une boucle de plantages la remplit en permanence, et le compte ne grandit jamais. Il compare désormais l'heure du plantage le plus récent, et une publication qui plante en boucle échoue et restaure la version précédente.

Ce qu'attend une publication

Lorsque vous publiez une application avec un backend sur Mythex, la nouvelle version est déployée sur des machines de notre plateforme d'hébergement, et un contrôle de santé décide si la publication est passée en ligne ou a échoué. En cas d'échec, une restauration remet la version précédente.

La difficulté, c'est que « démarré » n'est pas la même chose que « en service ». La plateforme indique qu'une machine est démarrée dès qu'elle est en marche. Une application qui plante une seconde après son démarrage est relancée immédiatement, et un instant plus tard elle apparaît de nouveau comme démarrée. Le contrôle de santé s'était donc enrichi de plusieurs couches au fil du temps :

1. Regarder deux fois. Une fois qu'une machine apparaît comme démarrée, on attend brièvement puis on regarde à nouveau. Un plantage au démarrage échoue souvent au second regard.
2. Surveiller les boucles de plantages. Si la plateforme signale qu'une machine a planté en boucle et qu'elle a abandonné les redémarrages, on échoue.
3. Compter les plantages depuis le début de la publication. Deux regards « démarré » peuvent encadrer un redémarrage. Si un plantage est survenu depuis le début de cette publication, on regarde une troisième fois ; si l'on compte plus de plantages qu'au regard précédent, l'application ne tient pas.

La troisième vérification est celle qui a échoué ici.

Pourquoi le compte restait plat

Les informations de plantage viennent de la liste d'événements de chaque machine : démarrages, sorties, redémarrages. La plateforme ne conserve que les cinq derniers événements par machine.

Imaginez une application qui plante 2,5 secondes après chaque démarrage, comme l'une d'elles. Chaque cycle ajoute un plantage et un démarrage. Au bout de quelques cycles, la liste est pleine. À partir de là, chaque nouvel événement en repousse un ancien. La liste glisse vers l'avant, mais elle contient toujours à peu près le même mélange : quelques plantages, quelques démarrages.

Ainsi, « combien de plantages depuis le début de la publication » renvoyait le même nombre à chaque regard. Le second regard voyait, disons, deux plantages. Le troisième en voyait aussi deux — des plantages différents, mais le même compte. La vérification en concluait que les plantages avaient cessé, et validait la publication.

Cela s'est produit trois fois le 25 septembre, sur deux applications. À chaque fois :

• la publication était marquée comme en ligne,
• aucune restauration n'était lancée, puisque rien n'avait échoué,
• notre réconciliateur, une tâche de fond qui vérifie les déploiements après coup, a fini par faire échouer le déploiement quelques minutes plus tard,
• et le site entier renvoyait une erreur 404.

Une publication qui échoue à temps peut être récupérée : la restauration remet la version précédente. Une publication qui échoue quelques minutes en retard, après avoir été déclarée réussie, a déjà sauté sa restauration.

Comment nous l'avons trouvé

Nous l'avons reproduit en local : nous avons pris une API qui fonctionnait, l'avons laissée se mettre en veille, puis l'avons republiée avec une modification qui plantait au démarrage. Le contrôle de santé l'a déclarée en ligne.

Cela correspondait à la production : dans chacune des trois publications, l'application mourait quelques secondes après chaque démarrage, pourtant le compte de plantages que comparait le contrôle ne progressait jamais entre deux regards.

La correction : comparer le plantage le plus récent, pas le compte

Au lieu de compter les plantages, le contrôle regarde désormais l'heure du plantage le plus récent survenu depuis le début de la publication.

Si le second regard montre un plantage survenu depuis le début de la publication, le contrôle attend et regarde une troisième fois. Si le plantage le plus récent au troisième regard est postérieur à celui du second, la machine a planté de nouveau entre-temps. Elle ne tient pas, et la publication échoue avec un message indiquant que la machine a planté à répétition depuis la publication et redémarre encore.

Cela fonctionne quelle que soit la longueur de la liste d'événements. Une fenêtre glissante de cinq événements peut masquer le nombre de plantages, mais elle ne peut pas masquer qu'un nouveau vient de se produire : l'événement le plus récent est toujours celui qui est conservé.

Avec cette modification, la reproduction locale se comporte correctement : la publication échoue, et l'image précédente est restaurée. Un test simule le comportement de la plateforme — à chaque regard, un plantage et un démarrage s'ajoutent et la liste est ramenée à cinq — et vérifie que le verdict est un échec, pas une réussite.

Ce que nous en retenons

• Connaître la forme des données que vous comptez. Un compte sur une liste limitée ne veut plus rien dire une fois la liste pleine. La limite n'était pas cachée ; nous n'avions simplement pas conçu le contrôle en tenant compte d'elle.
• Préférer « est-il arrivé quelque chose de nouveau ? » à « combien en est-il arrivé ? ». L'horodatage le plus récent survit à la troncature. Un total, non.
• Un échec tardif est pire qu'un échec précoce. La même version cassée est sans danger si la publication échoue et revient en arrière, mais elle met un site hors ligne si elle est d'abord déclarée réussie.
• Reproduisez dans les conditions réelles. Le bug exigeait une machine ayant déjà assez planté pour remplir sa liste d'événements. Un seul plantage rapide dans un test n'aurait pas permis de le voir.

Cette correction va de pair avec une autre, du même jour, qui a veillé à ce que la restauration remette l'ancienne version au lieu de la supprimer : une republication ratée ne supprime jamais un backend qui fonctionne. Si votre propre application ne se publie pas parce qu'elle plante au démarrage, la documentation de dépannage de la publication et notre guide sur le débogage d'une application créée avec l'IA sont de bons points de départ.