멈춘 상태값과 재수집의 부재

품절 처리를 했는데 주문이 계속 들어온다는 문의가 왔다. distribution_products 를 SELECT 해 보니 상태가 여전히 판매 중이었다.

SELECT channel_product_status, updated_at
  FROM distribution_products WHERE id = ?;

channel_product_status 가 normal 이라 중지가 안 나간 것처럼 보였다.

Open Table of contents

증상 — 품절인데 들어오는 주문

처리가 안 나갔다고 보면 다시 보내는 것이 다음 순서였다. 그런데 그 값이 어디서 채워지는 컬럼인지를 먼저 확인하기로 했다.

확인해 보니 channel_product_status 는 우리가 쓰는 값이 아니라 수집 배치가 외부 상태를 조회해 UPDATE 로 채우는 컬럼이었다.

수집 배치 실행 → 외부 상태 조회 → 컬럼 갱신

그러면 그 값은 마지막으로 수집한 시점의 상태를 담고 있는 것이었다.

같은 행의 updated_at 이 중지 처리 시각보다 앞이었다.

중지 처리      3월 2일
updated_at    2월 18일

중지 처리 뒤로 이 행이 한 번도 안 바뀐 것이다.

즉 이 값은 품절 처리 이전에 수집된 것이고 그 뒤로 한 번도 갱신되지 않았다. 처리가 반영 안 된 것이 아니라 반영 여부를 볼 수 있는 값이 아니었다.

수집으로 채워지는 컬럼은 다시 수집해 UPDATE 하지 않으면 마지막 수집 시점에서 멈춘다. 실제 상태가 어떻게 바뀌든 그 값은 그대로 있다.

그래서 이런 컬럼을 볼 때는 값과 updated_at 을 함께 봐야 한다. updated_at 이 문제 발생보다 앞이면 그 값으로는 아무것도 판단할 수 없다.

다행히 수집할 때 받은 원본 응답을 그대로 저장해 둔 자리가 있어서 그것을 열어 봤다. 거기에는 외부 시스템이 준 상태 코드가 그대로 들어 있었다.

그 코드가 무엇을 뜻하는지를 문서로 확인해 보니 품절에 해당하는 코드였다. 우리 화면의 값과 저쪽 코드가 일대일로 맞지 않아서 확인이 필요한 자리였다.

여기에 주문 표와 JOIN 해 실제 이력까지 교차로 봤는데 문의에서 말한 주문들이 품절 처리 이전에 들어온 건이었다. 처리 뒤로는 새로 들어온 것이 없었다.

멈춘 값만 보고 다시 보냈으면 이미 된 것을 한 번 더 하는 셈이었다. 값과 시각과 원본과 이력 넷을 맞춰 보고 나서야 조치가 필요 없다는 답이 나왔다.