몇몇 업체의 상품 수정이 계속 실패하면서 INVALID_PRODUCT_NO 와 기본정보 조회가 안 된다는 메시지가 나왔다. 상품번호 자체의 문제로 보이는 메시지였다.
Table of contents
Open Table of contents
배경 — 등록만 성공하는 패턴
이상한 점이 있었는데 같은 업체의 신규 등록은 전부 성공하고 있었다. channel_jobs 를 GROUP BY job_type, result 로 세니 CREATE 만 실패가 0이었다.
인증 문제라면 등록도 실패해야 하고 인증 오류 코드가 와야 하는데 둘 다 아니었다. 인증은 맞는데 특정 작업만 실패한다는 조합이 원인을 다른 축으로 옮겼다.
원인 — 토큰 기준의 조회 범위
외부 시스템의 동작을 확인하니 토큰 안의 site_id 를 기준으로 기존 상품을 조회하고 있었다. 우리 쪽 연결을 보니 channel_products.seller_id 와 연결된 channel_accounts.site_id 가 서로 달랐다.
그러면 등록은 조회할 대상이 없으므로 그냥 만들어져 성공하고 수정과 중지는 기존 상품을 조회하는데 다른 사이트 것이라 못 찾아 실패한다. 조회 범위 불일치였다.
주의 — 인증 오류로 안 나오는 이유
이것이 왜 인증 오류 코드로 안 나오는지도 분명했다. 인증 자체는 성공했고 토큰이 유효하다.
그 토큰으로 조회할 수 있는 범위에 그 상품이 없을 뿐이므로 외부 입장에서는 404 에 해당하는 정상 응답이다. 우리 쪽에서만 이상해 보이는 응답이고 등록만 성공하면서 조회 관련 오류가 나오면 이 패턴을 의심하면 된다.
검증 — 대조군과 잠재 대상
가설을 확정하려고 같은 데이터인데 올바른 경로로 연결된 건들을 찾아 대조군으로 삼았다. 그쪽은 수정과 중지 실패가 0건이었다.
문의 온 세 건만 고치면 되는지도 확인하려고 site_id 가 어긋난 조건을 전부 셌더니 수십 개 업체에 천 건 넘게였다. 두 가지 방법이 있었는데 문의 온 세 건만 고치는 것과 1,300여 건을 한 번에 재연결하는 것이다. 뒤쪽을 골랐다. 이유는 문의 온 것만 고치면 나머지가 순차로 돌아와서다. 대신 재연결 배치를 짜고 검증하느라 세 건의 회신이 며칠 늦어지는 것을 감수했다.
조치 — 등록 성공이 근거가 아닌 이유
이 건에서 규칙 하나가 나왔는데 등록이 성공한다는 것만으로 연결이 옳다고 판단하면 안 된다는 것이다. 새 연동을 붙이고 등록이 되면 됐다고 생각하지만 수정과 중지는 나중에 필요해지고 그때 실패한다.
그래서 연동 검증 체크리스트에 UPDATE 와 SUSPEND 까지 포함하기로 했다. 이 조사에서 결정적이었던 것은 작업 유형별로 나눠 센 것인데 전체 실패율만 봤으면 가끔 실패한다는 결론이었고 나눠 보니 특정 유형만 90퍼센트 실패한다는 것이 드러났다.
정리
- 등록은 되는데 수정과 중지만 실패하면 조회 범위를 의심한다
- 외부가 토큰의 식별자 기준으로 기존 항목을 조회할 수 있다
- 범위 불일치는 인증 오류가 아니라 조회 오류로 나타난다
- 외부 입장에서는 그것이 정상 응답이다
- 대조군이 0건이어야 가설이 선다
- 잠재 대상을 세지 않으면 문의 온 것만 고치고 끝난다
- 등록 성공만으로 연결이 옳다고 판단하지 않는다
- 작업 유형별로 나눠 세면 가끔이 특정 유형만이 된다