pending은 오류가 아니다

한 채널의 교환 주문이 만들어졌는데 후속 교환 주문이 안 생긴다는 문의가 왔다. 오류 로그는 어디에도 남아 있지 않았다.

Open Table of contents

성공 건과 방치 건의 대조

같은 유형에서 정상으로 처리된 건이 있어서 그것과 안 된 셋을 나란히 놓고 상태를 비교했다. 성공한 건만 일차 교환 항목이 교환 상태를 유지하고 있었고 그 아래에 반품 항목이 살아 있었다.

방치된 셋은 일차 항목이 결제 취소나 출고 완료로 바뀌어 있었고 반품 항목이 없었다. 오류 로그가 없을 때 성공 건과 나란히 놓는 것이 유일한 출발점이었다.

코드를 보니 일차 교환 항목의 반품 항목을 찾아 매핑하는데 없으면 대기라는 값을 돌려주고 있었다. 예외를 던지는 것이 아니라 정상 흐름의 한 상태로 다루고 있었다.

그리고 반품 항목은 일차 항목이 교환 상태를 유지할 때만 살아 있다. 선행 상태가 다른 값으로 바뀌면 그 항목이 사라지므로 매핑이 영영 성립하지 않는다.

대기 값을 받은 호출부는 상태를 대기로 바꾸고 다음에 다시 시도하겠다는 전제로 넘어간다. 그런데 다시 시도해도 선행 상태는 안 바뀌므로 같은 결과가 나온다.

재시도로 풀리는 대기와 안 풀리는 대기를 구분하지 않으면 뒤의 것이 영구 정지 상태가 된다. 코드는 정상 흐름을 돌고 있고 결과만 영원히 나오지 않는다.

예외가 아니므로 오류 로그가 없고 실패로 세지 않으므로 실패 지표도 없다. 정상 흐름의 한 상태이므로 알림도 걸려 있지 않다.

그래서 고객이 교환이 안 됐다고 말할 때까지 아무도 모른다. 문의가 사실상 감시 역할을 하고 있는 상태였다.

대응 방법을 정하기 전에 이 유형을 전에 수동으로 처리한 적이 있는지 조회했다. 전 채널과 전 기간에 걸쳐 하나도 없었다.

선례가 있으면 그것을 따르면 되고 없으면 내가 만드는 것이 선례가 되므로 무엇을 왜 했는지 남겨야 한다. 없다는 것도 조회로 확인해야지 안 찾아보고 없을 것이라고 말하지 않는다.