앱이 꺼져 있거나 PC가 잠든 동안 예약 시각이 지날 수 있다. 다시 켰다고 과거 작업을 전부 실행하면 늦은 발송이나 중복 게시가 될 수 있다. 나는 지정 시각을 놓친 경우와 실행 중 끊긴 경우를 나눠 기록하고, 새로 보낼지 판단하기 전에 원래 상태를 읽도록 했다. 다시 시작했다는 사실을 새 실행의 허락으로 삼지 않은 것이다.

아직 시작하지 않은 지각을 먼저 구분한다

ProjectJobs는 queued의 예정 시각이2분 넘게 지났으면 missed와 시간 초과 이유를 저장하고 dispatch하지 않는다. 카페 큐는 같은 초과 조건을 failed와 DELIVERY_TIME_MISSED로 남긴다. 코드의 상태 이름은 다르지만 과거 작업을 무조건 따라잡지 않는 경계라는 목적은 같다.

2분은 현재 구현의 기준이며 모든 업무에 맞는 일반 법칙은 아니다. 허용 지연을 넘긴 예약은 조용히 실행하거나 시각을 바꾸지 않고, 실행되지 않았음을 알려야 한다. 사용자는 왜 실행되지 않았는지 보고 새로운 시각과 의도를 정할 수 있어야 한다. 늦게 보낸 결과를 원래 정시 실행으로 보고하지 않는다.

폴더 실행의 시작 지연은 별도 상태다

폴더 worker도 시작 시각이2분 넘게 지났으면 overdue로 남긴다. 첫 항목 함수에서도 시작 지연을 확인해 unconfirmed로 멈추는 경계가 있다. 이 경로는 일반 예약 큐와 다른 실행기이므로 같은 상태 필드가 있다고 설명하지 않는다.

원래 공개 시각을 뒤로 밀어 새 예약으로 만드는 기능도 아니다. 폴더의 공개 일정과 worker 시작 시각은 이미 다른 자료다. 나는 어느 시간이 지났고 어떤 일이 아직 시작되지 않았는지 따로 읽어야 한다고 본다. “예약 실패”라는 한 문구만으로 원인과 다음 행동을 모두 결정하기는 어렵다.

running 기록은 새 queued로 돌리지 않는다

재시작 때 running으로 남은 일반 예약과 카페 기록은 needs_review로 바꾼다. 프로세스가 없다고 외부에 전달된 행동까지 없었다고 볼 수 없기 때문이다. 원래 runId와 남은 파일이 있다면 그 결과부터 확인해야 한다. 시작 여부가 애매한 일을 새 ID로 우회하는 안내는 하지 않는다.

기존 단위 시험은 running 기록을 다시 열고 실제 dispatch 호출이0인지 본다. 이것은 모든 전원 차단 상황의 실현장 재현은 아니다. 이번 집필에서도 사용자 PC를 절전하거나 원래 앱을 종료하지 않았다. 상태 복원의 코드와 기존 시험이 확인한 조건을 나눠 설명한다.

필요한 자동 확인은 재전송과 다르다

카페 큐에는 알려진 runId와 특정 오류, 버전별 확인 조건이 맞을 때 원래 게시 결과를 조회하는 경로가 있다. 앱은 그 경우 operation을 verify-published로 바꾼다. 모든 needs_review를 다시 publish하는 규칙이 아니다. 조회를 한 번 더 한다는 것과 새 제출을 만든다는 것은 다른 행동이다.

폴더 게시 도우미도 기존 run ID를 찾으면 페이지 준비와 파일 선택을 다시 하지 않고 그 실행을 조회한다. 기록이 있는데 run ID가 없다면 자동 재전송하지 않는다. 나는 중단 뒤 자동화가 전부 멈춰야 한다는 설명보다 어떤 읽기만 허용하고 어떤 변경을 금지하는지 구체적으로 남기려 했다.

재개는 paused와 미래 조건을 다시 확인한다

예약의 resume는 해당 소유 범위에서 paused이고 예정 시각이 미래일 때만 허용한다. missed나 needs_review를 버튼 하나로 queued로 바꾸는 일반 복구 기능이 아니다. 원래 결과와 자료, 현재 시각을 읽은 뒤 필요한 새 요청을 정해야 한다.

로컬 등록 도중 응답이 끊긴 경우도 주의해야 한다. 실행 연결은 중단 오류를 보고하며 상태에서 실제 등록 여부를 확인하라고 한다. 같은 register를 새로 보내는 방식으로 완료를 추측하지 않는다. 등록을 요청한 사실과 등록 기록을 읽은 사실, 외부 업무 완료를 서로 다른 단계로 유지한다.

늦은 자동 실행보다 판단 가능한 기록을 남긴다

사용자는 예약을 믿고 자리를 비운다. 그러므로 놓친 일을 나중에 숨겨서 처리하기보다 놓친 이유와 이미 진행된 범위를 알려 주는 것이 필요하다. 나는 정확한 시각에 처리할 수 없었던 조건도 기능의 결과라고 본다. 성공 횟수만 세면 그 사실이 사라진다.

회사 프로그램에서 청구와 알림, 자료 전송을 예약할 때도 같은 문제가 있다. 늦어도 해도 되는 업무인지 현재 의도가 남아 있는지 확인해야 한다. 예약을 설계하는 일은 타이머를 넣는 것뿐 아니라 시간이 지나도 사용자의 선택을 임의로 대신하지 않는 상태를 만드는 일이었다.