뒤 클레임을 막은 앞 상태

반품 요청이 처리되지 않는다고 해서 클레임이 수집됐는지부터 확인했다. 주문 식별자로 조회했더니 아무것도 안 나왔다.

Open Table of contents

우리 id가 아니던 연결 키

테이블 정의를 열어 보니 주문 식별자 컬럼에 들어가는 값이 우리 내부 식별자가 아니었다. 채널이 부여한 주문 번호가 그 자리에 들어가고 있었다.

컬럼 이름이 우리 쪽 키를 뜻하는 것처럼 보여서 그대로 조회한 것이 문제였다. 상대 번호로 다시 조회하니 두 건이 나왔다.

두 건 중 교환 클레임은 정상이고 반품 클레임이 오류 상태로 며칠째 멈춰 있었다. 사유를 보려고 로그 컬럼을 열었더니 값이 비어 있었다.

실패했다는 것만 있고 왜 실패했는지가 없는 상태였다. 직접 근거가 없으므로 주변 상태 데이터로 추론하는 수밖에 없었다.

해당 아이템의 상태를 조회하니 교환 재출고 배송 중이었다. 같은 아이템 위에 교환이 진행 중인데 반품 클레임을 만들려던 상황이었다.

앞선 처리가 진행 중이면 다음 클레임 생성이 막히는 구조로 보였고 두 사실이 나란히 있는 것이 그 근거였다. 다만 로그가 비어 있어 코드로 확정한 것은 아니었다.

이런 경우 클레임 가져오기를 다시 돌리는 대응이 흔한데 여기서는 안 된다. 수집은 이미 성공해서 레코드가 있고 실패한 것은 생성 단계였다.

수집을 몇 번 돌려도 앞 상태는 안 바뀐다. 그래서 교환을 먼저 철회하고 상태를 정리한 뒤에 수집된 클레임을 재처리하는 순서로 절차를 짰다.

같은 레코드의 부가 정보 필드를 열어 보니 자동 환불 예정일이 들어 있었다. 채널이 고객 환불을 자동으로 처리한다는 뜻이므로 우리가 환불까지 하면 이중 처리가 된다.

기록할 때는 조회로 확인한 두 사실과 충돌이 원인이라는 정황 추정을 나눠 적었다. 추정을 확정으로 적으면 다음에 같은 오류를 볼 때 교환이 없는 경우가 조사에서 배제된다.