Quiz: reception, execution, and business effects

웹훅에는 HTTP 200이 돌아왔지만 Workflow가 없다. 가장 적절한 다음 확인은?

• 해당 요청의 추적 ID로 구독 상태·필터 판단·제출 오류를 나눠 확인한다
• 접수 응답이 성공이므로 완료된 Workflow의 자동 삭제만 조사한다
• 이벤트 수신 문제이므로 원문을 보존하지 않고 같은 요청을 반복한다
• 필터가 정상 거부한 것으로 판단하고 다음 요청부터 성공으로 센다

order.created 패턴이 pre-orderXcreated-tail도 승인했다. 정확한 종류 하나만 허용하려면?

• 정규식은 유지하고 EventBus의 메시지 보존 시간을 줄인다
• 정규식은 유지하고 Sensor의 의존성 이름을 새로 바꾼다
• 시작과 끝을 고정하고 점을 문자로 취급하는 패턴으로 바꾼다
• 정규식은 유지하고 Workflow의 생성 이름 접두어를 바꾼다

bool 필터에 문자열 true와 숫자 1도 통과했다. JSON 불리언 true만 허용해야 한다면?

• 전달된 값이 참으로 변환되므로 현재 필터만 그대로 유지한다
• 원래 값의 타입과 값을 모두 검사한 뒤 정상·비정상 입력을 비교한다
• Workflow 파라미터를 문자열로 바꾸고 Sensor의 검사는 제거한다
• 숫자 비교 필터를 추가해 1 이상이면 모두 정상 입력으로 허용한다

Sensor의 Workflow 생성이 forbidden이다. 이 실습의 Kubernetes 생성 트리거를 복구하는 방법은?

• Workflow 실행 계정에 모든 Secret의 조회 권한을 추가한다
• Sensor 제출 계정에 클러스터의 모든 리소스 수정 권한을 준다
• EventSource 계정에 Pod 생성 권한을 주고 Sensor는 유지한다
• Sensor 제출 계정에 Workflow create를 허용하고 새 이벤트로 확인한다

같은 주문 ID로 서로 다른 Workflow 두 개가 성공했지만 장부에는 한 번만 반영됐다. 올바른 해석은?

• 실행은 두 번이고 업무 효과는 한 번이며 업무 키 기준 중복 억제를 확인했다
• 업무 효과가 한 번이므로 EventSource에는 HTTP 요청이 한 건만 도착했다
• 워크플로 두 개가 성공했으므로 브로커가 같은 메시지를 재전달했다고 증명했다
• 장부 효과가 한 번이므로 외부 결제와 이메일도 항상 한 번만 처리된다

같은 업무 키로 금액이 달라진 요청이 도착했다. 실습 장부의 올바른 처리는?

• 중복 키이면 금액을 비교하지 않고 항상 이전 성공 응답을 돌려준다
• 새 금액이 더 크면 차액을 더하고 동일 주문의 정상 재시도로 기록한다
• 기존 요청과 본문이 다르므로 충돌로 거부하고 원래 반영을 유지한다
• 기존 장부 행을 지운 뒤 새로운 금액을 반영하고 중복 기록을 초기화한다