저자는 세션 시작, 파일 전송, 비디오 ID 검색, 검증, 로컬 레코드 생성으로 이어지는 순차적 프로세스를 포함하는 YouTube 업로드 시스템을 개발했습니다. 로컬 레코드가 검증 단계 이후에만 기록되었기 때문에 치명적인 결함이 발생했습니다. 검증에 실패하면 예외가 프로세스를 중단시켜 디스크에 업로드된 비디오에 대한 기록이 남지 않았습니다. 결과적으로 업로드 명령을 다시 실행하면 기존 파일 검사를 우회하여 비디오가 중복 업로드되었습니다.시스템의 문서는 재시도가 중복을 생성하지 않을 것이라고 오해의 소지가 있게 명시했지만, 이는 전체 프로세스 실패 후 외부에서 다시 실행하는 것이 아니라 내부 저수준 재시도에만 적용되었습니다. 이로 인해 동일한 비디오가 두 번 업로드되었습니다. 저장소의 다른 부분에서도 유사한 버그가 발견되었는데, 이전 프로세스를 통해 업로드된 5개의 비디오도 해당 로컬 레코드가 없어 중복에 취약했습니다.저자는 기존 테스트가 예외 발생 후 디스크의 시스템 상태를 고려하지 않았기 때문에 통과했다고 강조합니다. 수정 사항은 검증되지 않은 것으로 표시되더라도 비디오 ID를 받은 직후 로컬 레코드를 기록하도록 워크플로우를 변경하는 것을 포함했습니다. 이 레코드는 검증을 재개하거나 비디오가 이미 처리된 경우 추가 업로드를 차단하는 데 사용될 수 있습니다. 기존 5개 비디오의 경우 수동으로 레코드를 백필해야 했습니다.핵심 문제는 원격 리소스를 생성한 다음 이를 검증하고, 실패 시 원격 리소스는 생성되었지만 로컬 상태는 기록되지 않은 상태로 둘 수 있는 창을 만드는 모든 작업으로 일반화됩니다. 이러한 모호성은 재시도 로직을 비효율적으로 만듭니다. 솔루션은 후속 검증에 관계없이 식별자를 받는 즉시 기록하는 것을 강조합니다. 또한 리소스를 생성하는 모든 코드 경로가 보이지 않는 불일치를 방지하기 위해 동일한 장부 시스템에 기여해야 함을 강조합니다.