배송정책 화면에 대해 전송해야 하는 마켓이 십여 곳인데 상태가 하나만 뜨는 것이 맞느냐는 질문을 받았다. 마켓별로 십여 개 상태가 떠야 할 것처럼 보이는데 하나만 있었다.
Table of contents
Open Table of contents
조사 — 정책의 단위
먼저 이 정책이 무엇 단위인지를 확인했다. shipping_policies 에 channel_id 가 있고 GROUP BY supplier_id, channel_id 로 세어 보니 채널마다 하나씩이었다.
마켓 계정 단위가 아니라 채널 단위로 하나씩 존재한다. 그러면 한 정책은 한 채널에 대응하므로 십여 개 마켓에 대한 십여 개 상태가 아니다.
원인 — 상태가 세는 것
화면 상태를 만드는 syncStatus() 를 봤다. 연결된 channel_jobs 중 latest() 하나의 status 만 반환하고 작업이 하나도 없으면 null 을 돌려준다.
화면은 그 null 을 미연동 으로 표시하고 있었다. 읽는 쪽은 그것을 연동이 실패했다는 뜻으로 받아들이는데 실제 뜻은 작업이 한 번도 생성된 적 없다는 것이었다.
실패로 읽었을 때의 결과
상태값 셋을 뜻으로 옮기면 미연동 은 만든 적 없음이고 PENDING 은 보내고 기다리는 중이며 SUCCESS 는 완료된 것이다. 미연동을 실패로 읽으면 왜 연동이 안 되는지를 찾아 로그를 뒤지게 된다.
그런데 로그에는 아무것도 없다. 시도한 적이 없기 때문이고 그 자리에서 조사가 막히는 것이 이 라벨의 비용이다.
작업이 안 생긴 이유
그러면 왜 작업이 안 만들어졌는지를 찾았다. 작업 생성이 ShippingPolicyController::store() 안에서만 일어나고 있었다.
그 컨트롤러를 거칠 때만 만들어지므로 배치로 만들었거나 이관 때 들어왔거나 직접 넣은 정책은 작업이 없다. 그런 정책은 아무도 손대지 않으면 영구히 초기 상태로 남는다. 해소에는 두 가지 방법이 있었는데 정책마다 화면에서 한 번 저장해 그 경로를 태우는 것과 작업 생성을 PolicyObserver 로 옮겨 어느 경로로 만들어져도 작업이 생기게 하는 것이다. 이번 건은 앞쪽을 골랐다. 이유는 해당 정책이 몇 개 안 되고 저장만 하면 끝나서다. 대신 이관이나 배치로 정책이 또 들어오면 같은 일이 반복되는 것을 감수했고 옵저버 이관은 백로그에 적었다.
결론 — 뒤집힌 질문의 전제
원래 질문으로 돌아가면 상태가 하나만 뜨는 것이 맞다. 이 정책은 한 채널의 것이고 상태도 그 채널에 대한 것이므로 열이 하나다.
십여 개 마켓을 보려면 채널별로 십여 개 정책이 있어야 하고 각각에 상태가 붙는다. 질문의 전제가 정책 하나가 여러 마켓에 나간다는 것이었고 그 전제가 틀렸다.
이 건의 원인은 라벨 하나였는데 미연동 이라는 말이 연동 시도의 결과처럼 읽히고 시도 자체가 없었다는 것을 안 알려 준다. 확인 순서로는 그 데이터가 무엇 단위인지와 화면 상태를 만드는 코드와 각 상태값의 조건과 그 데이터를 만드는 지점을 차례로 본다.
정리
- 화면 상태가 무엇 단위인지 먼저 확인한다
syncStatus()처럼 상태 추출이 마지막 하나만 보는 경우가 있다null을 표시용 라벨로 바꾸면 원래 뜻이 가려진다- 미연동이 실패가 아니라 작업 없음일 수 있다
- 실패로 읽고 로그를 뒤지면 아무것도 없다
- 특정 경로를 거쳐야 생기는 데이터가 있다
- 다른 경로로 만든 것은 영구히 초기 상태로 남는다
- 해소는 그 경로를 한 번 태우는 것이다