Quiz: Do Not Erase Failed Snack Orders

격리된 업무를 redrive할 때 초기화하면 안 되는 값은?

• 이전 선점부터 증가해 온 token
• 이번 예산에서 소비한 attempts
• 다시 접수 가능한 available_at
• 새 시간 예산의 deadline

redrive의 감사 행 삽입 뒤, pending 갱신 전에 예외가 났습니다. 올바른 디스크 상태는?

• 감사 행만 보존하고 업무는 dead로 두어 성공으로 보고한다
• 감사 행과 상태 변경을 모두 롤백해 기존 격리를 보존한다
• 감사 행은 지우고 업무만 pending으로 바꾸어 처리한다
• 기존 업무와 감사 내역을 삭제하고 새 업무 ID를 발급한다

앞 순서의 업무는 영구 오류로 dead가 됐고 뒤 업무는 유효합니다. 이 실습 큐의 처리 계약은?

• 앞 업무가 고쳐질 때까지 뒤 업무도 무기한 멈춘다
• 순서 보장을 위해 뒤 업무를 앞 업무와 함께 삭제한다
• 독립 업무이므로 뒤 업무는 처리하되 격리 기록을 남긴다
• 뒤 업무를 앞 업무 ID로 바꾸어 수신 중복으로 처리한다

수신 서버가 수량 7을 커밋한 직후 전달자가 종료되고, 다음 작업자가 같은 ID로 재전송했습니다. 기대 증거는?

• HTTP 요청 한 번, inbox 두 행, 업무 효과 14
• HTTP 요청 두 번, inbox 두 행, 업무 효과 14
• HTTP 요청 한 번, inbox 한 행, 업무 효과 0
• HTTP 요청 두 번, inbox 한 행, 업무 효과 7

send가 알 수 없는 예외를 냈습니다. run_once는 어떻게 처리해야 하나요?

• 예외를 전달하고 leased 기록을 남겨 만료 후 재선점하게 한다
• 모든 예외를 정상 ACK로 바꾸고 큐에 done을 기록한다
• 모든 예외를 Permanent로 바꾸고 감사 없이 업무를 삭제한다
• 외부 결과를 모르므로 attempts를 줄이고 즉시 반복 호출한다

격리 목록이 줄었습니다. 운영자가 성공 증가라고 판단하기 전에 확인할 것은?

• 큐 파일 크기만 비교하여 작아졌으면 모두 성공으로 센다
• done·redrive 감사·재시도 상태를 나눠 실제 이동 이유를 본다
• pending을 모두 done으로 표시한 뒤 성공률을 다시 계산한다
• 격리 사유를 지워 같은 업무가 다시 집계되지 않게 만든다