確認問題：取り消しも新しい変更

revision 3의 주문을 취소하여 4가 됐고, 이제 그 취소를 보상합니다. 새 버전은 무엇이어야 하나요?

• 처음 상태를 복원하므로 revision도 3으로 낮춘다
• 행 상태만 바꾸고 revision 4는 계속 재사용한다
• 보상도 새 변경이므로 revision을 5로 증가시킨다
• 누구나 재시도할 수 있게 revision을 0으로 초기화한다

원 changes에는 취소 승인이 있지만 해당 주문의 audit 행이 없습니다. load_plan은 어떻게 해야 하나요?

• 현재 cancelled 상태를 보고 빠진 감사 값을 추측해 채운다
• 현재 revision을 그대로 새 승인 버전으로 간주하고 계속한다
• 같은 건수의 다른 감사 행으로 원 기록의 빈자리를 대신한다
• 원 기록의 근거가 불일치하므로 Conflict로 계획 생성을 거부한다

undo_records의 undo_id뿐 아니라 original_id도 UNIQUE로 둔 이유는?

• 다른 보상 ID를 사용해 같은 원 변경을 두 번 복구하는 것을 막기 위해서다
• 서로 다른 원 변경도 한 번만 보상하도록 전체 테이블을 한 행으로 만들기 위해서다
• 사유 문자열만 같으면 모든 고객의 보상을 하나로 합치기 위해서다
• 현재 주문의 revision 비교를 생략하고 항상 복구해도 되게 하기 위해서다

같은 undo_id와 original_id로 사유만 다르게 제출했습니다. 이미 실행한 요청으로 False를 반환해도 되나요?

• 된다. 사유는 문자열이므로 보상 기록의 내용에는 포함되지 않는다
• 안 된다. 같은 보상 번호의 다른 요청 내용이므로 Conflict다
• 된다. 원 변경을 보상한 뒤라면 어떤 사유도 자동으로 덮어쓴다
• 안 된다. 기존 보상 영수증을 삭제하고 새 요청만 남겨야 한다

보상 커밋 뒤 성공 응답을 잃었고, 그 뒤 다른 담당자가 주문을 또 바꿨습니다. 동일 보상 ID의 재호출은?

• 현재 상태가 다르므로 원래 보상을 다시 실행해 일치시킨다
• 현재 테이블의 값을 기존 보상 영수증에 덮어 써서 완료로 만든다
• 기존 동일 영수증으로 False를 반환하며 이후 변경은 별도 대조한다
• 새 보상 ID를 생성하고 이후 변경을 지우는 복구를 자동 승인한다

DB 안에서 취소 주문 상태를 복구하는 보상이 검증됐습니다. 어디까지 적용 가능하다고 설명해야 하나요?

• 결제·택배·고객 이메일도 같은 트랜잭션으로 자동 복구됐다고 설명한다
• 클라이언트 종료 시험으로 서버 전원 장애 내구성도 증명됐다고 설명한다
• tenant가 있으므로 외부 호출자의 고객별 권한도 확인됐다고 설명한다
• 이번 DB 변경과 기록의 범위이며 외부 효과·내구성·권한은 별도라고 설명한다