Je prends le temps de blogger ici (et pas sur le blog de Devoxx France) pour revenir sur le couac concernant les annonces de Devoxx France, le mardi 18 février.
Il y a eu un premier envoi d’emails à 11h15, qui malheureusement, pour quelques speakers, ne contenait pas les bonnes informations. Certains ont pu croire que leurs propositions étaient placées en Backup, alors qu’elles étaient en fait refusées. Le souci a été corrigé rapidement et à midi, un deuxième email a cette fois-ci, donné les bonnes informations. Ajoutons à cela un bug dans la page de validation… tout était réuni pour un souci qui heureusement, n’a pas trop pris d’ampleur.
A 11h05, j’ai passé sur la production une version qui permet d’annoncer aux speakers la bonne ou la mauvaise nouvelle. Pour vous donner un peu plus d’informations, voici comment nous avons géré cela cette année. Nous avons revu chaque présentation. Pour chaque sujet, nous l’avons « pré-approuvé » ou « pré-refusé ». Nous avions laissé à « submitted » les propositions à mettre en Backup hier soir.
Ce matin, j’avais plusieurs opérations à faire, avec un peu de code, qu’en principe vous n’exécutez qu’une seule fois. Je déclenche chaque étape en appelant une URL dans mon navigateur, sur l’admin. Le code est asynchrone et non-bloquant, ce qui permet de faire cela en batch.
La première action devait :
- Charger toutes les propositions marquées comme étant « approuvées » dans un set Redis
- Charger toutes les présentations marquées comme étant « refusées » dans un autre set Redis
- Charger toutes les propositions avec pour l’instant l’état « submitted »
- Si la proposition est approuvée, alors passer le sujet à « approved »
- Si la proposition est refusée, modifier le sujet et le passer à « rejected »
Dans un deuxième temps, une autre action était chargée de :
- Charger toutes les propositions avec maintenant l’état « approuvées »
- Charger toutes les présentations « refusées »
- Charger toutes les présentations « submitted »
- Faire un diff entre cette liste complete, à laquelle on retire les approved (160) et les refused (290)
- prendre ce résultat (en principe 20 talks) et marquer le sujet à « backup »
- Faire l’envoi d’emails aux speakers
Le souci a été que je n’ai pas assez attendu avant de lancer la 2eme étape. Le script, censé passer à Refused l’ensemble des talks, n’a pas terminé. Dès lors, lorsque j’ai validé l’envoi d’email… une partie des sujets qui étaient encore en « submitted » et pas passés en « rejected », sont passés à « backup ».
Malheureusement l’écran de validation avait un bug pour les sujets « Backup« . C’est cela qui a généré un souci important. Il permettait aux speakers d’Accepter un talk… qui normalement doit rester en Backup. C’est l’équipe qui recontactera chaque speaker, afin de lui proposer de jouer un talk « backupé » (ce qui représente 10-15 talks sur 450/470 je crois, tout format confondu… à vérifier)
Plusieurs raisons :
- la notion de Backup n’était pas implémentée, ce qui est un tort de ma part. Je n’aurai pas dû la calculer en faisant un diff entre les acceptés, les refusés et donc les autres propositions. Je n’aurai jamais dû mettre ce code dans la 2e action. Stupide.
- je me suis fait aussi avoir par la latence entre le serveur de prod et le serveur Redis. C’est super de faire du code asynchrone. Le souci ici c’est que j’ai enchainé 2 appels d’URLs, sans vérifier par moi-même que le premier traitement avait été effectué. Imaginez que vous lancez 2 procédures stockées, la deuxième étant dépendante du résultat de la première.
Grâce à Twitter, avec l’aide d’Arnaud Héritier aussi qui a géré tout de suite le souci, on a pu répondre et temporiser le souci. Il a suffit de déplacer le code qui place les talks « en backup » et de rejouer les 2 actions.
Désolé auprès des quelques speakers qui ont reçu un email leur disant qu’ils étaient backup au lieu de refusé.
En compensation, je propose d’offre un pass trois jours à tous les concernés O:-)
(j’aurai essayé)
Merci pour ce retour en tout cas. Et bon courage pour la suite de l’organisation !
Les tests ils sont ou ?