예약 실행 자리부터 얻은 뒤 running 상태를 저장하다 실패하면 정리 함수에 도달하지 못할 수 있다. 실제 일은 시작하지 않았는데 다음 일도 계속 막히는 오류다. 나는 정상 완료 경로에만 있던 정리를 실패 경계에서도 보장하도록 보고, 저장 실패와 외부 결과 미확정을 서로 다른 사실로 남기게 했다.
실행 전에 저장이 실패하는 경우부터 나눴다
ProjectJobs는 차선을 얻고 host 가능 여부를 확인한 뒤 running을 저장한다. 이 저장이 실패하면 dispatch를 하지 않고 검토 상태를 남기는 경로로 간다. 바깥 finally는 확보한 release를 호출한다. 실제 실행도 안 했는데 차선만 남는 상황을 막기 위한 순서다.
기존 E02 시험은 이 지점의 save를 한 번 실패시킨다. execute 호출은0이고 host 차선은 비어야 한다. 같은 프로젝트에 새 예약을 만든 뒤 정상 실행되는지도 본다. 오류 메시지를 표시했다는 것만으로 잠금이 회복됐다고 보지 않고 후속 작업의 실제 경로를 확인한다.
실행 뒤 저장 실패는 다른 위험을 가진다
dispatch가 이미 성공한 뒤 최종 결과와 fallback 검토 저장이 모두 실패할 수도 있다. 이때 외부 실행을 다시 하면 안 된다. 메모리의 항목을 needs_review로 남기고 소유한 두 차선은 해제한다. 기록 실패 때문에 프로젝트 전체가 영구 정지되는 것과 불확실한 기존 항목을 재실행하는 것을 모두 피하려는 처리다.
기존 시험은 dispatch를1회만 수행한 뒤 연속 저장 오류를 만들고 다음 tick에도 호출 수가 늘지 않는지 본다. 저장이 회복된 뒤 다른 새 항목은 실행된다. 나는 자원을 풀었다는 사실을 원래 항목이 안전하게 재시도 가능하다는 뜻으로 바꾸지 않는다. 잠금 해제와 업무 재실행 권한은 다른 조건이다.
다른 큐에서는 미저장 검토 상태도 따로 기억한다
DeliveryQueue는 unsavedReview에 저장하지 못한 항목을 기억하고 list에서 디스크 기록보다 우선해 보여 준다. 다음 claim에서도 그 항목을 건너뛴다. 파일이 예전 queued나 running이라고 같은 프로세스가 다시 전달하지 않도록 보완한 것이다.
이 메모리는 앱이 꺼진 뒤까지 남는 영속 저장이 아니다. 재시작하면 실제 디스크 기록과 recover 경로를 읽어야 한다. 저장장치 오류가 계속되는데도 모든 복구가 끝났다고 말할 수 없다. 나는 잠금 누수를 고쳤다는 결과와 기록 내구성의 남은 한계를 함께 설명하는 것이 필요하다고 봤다.
한 항목의 실패가 이미 확보한 이웃을 버리지 않는다
카페 큐는 먼저 확보한 항목들을 모아 실제 dispatch를 실행한다. 뒤 항목의 running 저장이 실패해도 앞에서 이미 확보한 다른 프로젝트 항목을 버리지 않아야 한다. 처리 뒤에는 각각의 차선이 풀려야 한다. Promise.allSettled와 오류 모음은 이웃 결과를 끝까지 읽는 경로에 사용된다.
기존 시험은 뒤쪽 항목만 저장 실패로 만들고 앞선 항목은1회 실행해 성공을 보존하는지 확인한다. 이것은 오류를 무시한다는 뜻이 아니다. 실패는 최종 오류로 보고하되 독립된 진행의 결과도 잃지 않는 것이다. 모든 항목을 한 실패 문장으로 덮으면 다음 진단에 필요한 정보가 사라진다.
검수 기록의 실제 층을 구분한다
0.1.167의 기록에는 단위 오류 주입과 소유한 Electron·MCP 프로필의 저장 실패 시험이 구분돼 있다. 실제 Python 플러그인 후속 실행과 기존 자료 보존도 당시 범위로 남아 있다. 실제 카페 게시와 새 영상 업로드를 했다는 기록으로 바꾸지 않는다.
이번 콘텐츠 작업은 해당 함수와 시험 코드를 읽었으며 원래 앱에 오류를 주입하지 않았다. 공개 차선 모듈은 소유 증표 비교, 파일 원장 모듈은 독립 저장 실패를 각각 시험한다. 이 근거들을 합쳐 전체 저장장치와 모든 서비스의 장애 복구를 보장하지 않는다. 무엇을 직접 실행했는지와 무엇을 읽었는지를 남긴다.
오류 뒤에도 진행할 수 있는 범위를 설명한다
운영자는 저장 오류 뒤 아무것도 못 하게 되면 같은 프로그램을 다시 켜고 처음부터 실행하기 쉽다. 나는 실패 항목은 확인 필요로 남기면서 다른 독립 업무의 실행 자리는 돌려주는 방식이 낫다고 생각한다. 프로그램의 잠금이 오류의 영구 기억이 될 필요는 없다.
회사 업무에서도 장부 저장 실패와 다른 직원의 조회를 한꺼번에 막으면 문제의 범위가 커진다. 어떤 자원을 풀어도 되는지와 어떤 결과를 다시 확인해야 하는지 구분해야 한다. finally 한 줄의 의미는 오류를 덮는 데 있지 않고 소유한 자원을 돌려주면서 미해결 사실을 보존하는 데 있었다.