WeDispatch 1.2.1 : « Mes audios » réparé, et le test qui manquait
Un correctif, et l'histoire d'un bug qui n'apparaissait que chez les comptes ayant déjà produit un audio. Ce qui s'est passé, comment c'est corrigé, et ce qu'on a mis en place pour qu'il ne repasse plus.
La version 1.2.0 a redessiné dix écrans de l'espace client. L'un d'eux, Mes audios, s'ouvrait sur un message d'erreur. Pas chez tout le monde : uniquement chez les comptes ayant déjà produit au moins un audio — c'est-à-dire, précisément, chez ceux qui s'en servent. La 1.2.1 le corrige, et corrige aussi la raison pour laquelle nous ne l'avons pas vu venir.
Ce qui s'est passé
L'espace client est rendu côté serveur, puis les parties interactives — la recherche, les filtres, le bouton « charger plus » — reprennent la main dans votre navigateur. Entre les deux, il y a une frontière, et tout ce qui la traverse doit pouvoir être écrit sous forme de texte.
Nous avions confié à la liste des audios son dictionnaire de libellés. Il contient des phrases toutes faites, mais aussi quelques formules qui se calculent : « 12 audios affichés sur 40 », « Charger 20 audios de plus », le pluriel qui s'accorde tout seul. Ces formules-là sont du code, pas du texte, et le code ne traverse pas la frontière. Le serveur s'arrêtait à cet endroit précis, et la page renvoyait une erreur.
Le détail qui a fait passer la chose inaperçue : cette liste n'est rendue que s'il y a quelque chose à lister. Sur un compte vide — celui qu'on ouvre spontanément quand on vérifie une refonte — la page s'affichait parfaitement.
Le correctif
Les libellés ne traversent plus rien. Ils vivent maintenant dans un fichier que le serveur et le navigateur consultent chacun de leur côté ; seule la langue choisie passe d'un côté à l'autre. Au passage, l'encart de consommation du mois a été rendu défensif : si la base répond mal, l'encart s'efface, il n'emporte plus la page entière.
Le test qui manquait
Notre chaîne de vérification lance les tests puis compile l'application avant chaque mise en production. Elle n'a rien signalé, et c'était logique : les écrans de l'espace client sont calculés à la demande, pour chaque compte, avec ses données. Ils ne sont jamais construits à la compilation, donc la compilation ne peut pas les voir échouer.
Nous avons donc ajouté un contrôle qui ne rend rien du tout : il relit le code, repère les dictionnaires contenant des formules calculées, et refuse qu'ils soient confiés à un composant qui vit dans le navigateur. Nous l'avons d'abord relancé sur le code fautif pour vérifier qu'il attrapait bien le bug, puis passé sur les neuf autres écrans redessinés — Mes audios était le seul concerné. Ce contrôle tourne désormais à chaque mise en production.
Ce que nous en retenons
Un bug qui ne se déclenche que sur les comptes actifs est un bug qu'on ne voit pas depuis un compte de démonstration. La leçon n'est pas « tester plus », elle est « tester avec des données ». C'est le chantier suivant de notre côté : un parcours de vérification qui ouvre chaque écran du tableau de bord avec un compte réellement chargé, avant que vous n'ayez à nous le signaler. Merci à celui qui l'a fait.
Sonorisez vos articles avec WeDispatch
Ce blog sera lui-même sonorisé par WeDispatch. Envie de voir ce que ça donne sur vos contenus ?
Demandez une démo