한 채널에서 OPTION_MISMATCH 오류가 백 건 남짓 났다. 제안된 조치는 legacy_option_id 를 NULL 로 비우면 새 코드가 생성돼 해결된다는 것이었다.
Table of contents
Open Table of contents
검증 — 쪼개 세니 무너진 가설
두 가지 방법이 있었는데 제안대로 전부 바로 비우는 것과 조치하기 전에 쪼개 세는 것이다. 뒤쪽을 골랐다. 이유는 비우는 것은 되돌릴 수 없고 그 백 건 남짓이 한 원인이라는 보장이 없어서다. 대신 조치가 하루 늦어지는 것을 감수했다. job_type 과 seller_id 와 legacy_option_id IS NULL 과 status 네 축으로 쪼개 셌더니 전부 UPDATE 작업이었고 거의 전부가 그 값을 이미 가지고 있었다.
즉 값이 비어서 나는 문제가 아니었다. 값이 없어서라는 가설이 세 번째 축에서 그대로 무너졌고 쪼개기 전에는 백 건 남짓이 한 덩어리였다.
원인 — 강제 완료가 남긴 상태
channel_jobs 이력을 보니 이관 시점에 DONE 으로 표시되고 note 에 migration 이라고 적혀 있었다. 이관 때 등록 작업을 강제로 완료시킨 것이고 실제 마켓 API를 부르지 않았다는 뜻이다.
이관 전에 이미 마켓에 옛 구조 기반 코드로 등록돼 있었는데 이관은 우리 쪽 구조만 바꾸고 마켓 쪽은 안 건드렸다. 강제 완료라서 실제 호출이 없었기 때문이다.
주의 — 비워도 안 되는 이유
제안된 조치를 따라가 보면 그 컬럼을 비우면 OptionCodeGenerator 가 다른 기준으로 넘어가고 또 다른 새 코드가 만들어진다. 그런데 그것도 마켓에 저장된 옛 코드와는 다르다.
어느 기준으로 만들든 마켓에 저장된 것과 다르면 불일치가 그대로 남는다. 생각한 문제는 우리 쪽 코드 생성 기준이 틀렸다는 것이었고 실제 문제는 마켓과 우리 쪽 코드가 어긋나 있다는 것이었다.
조치 — 외부를 건드려야 하는 조치
맞추려면 한쪽을 다른 쪽에 맞춰야 한다. 연동을 해제하고 재등록해 새 코드로 등록을 태우거나 마켓의 옵션명 변경 기능으로 상대 쪽을 먼저 동기화하는 두 방법이다.
둘 다 마켓을 건드려야 하고 우리 쪽만 고쳐서는 안 맞는다. 이 결론이 조치의 성격 자체를 바꿨다.
배경 — 셋으로 갈린 유형
GROUP BY note, created_at 으로 쪼갠 결과 백 건 남짓이 세 유형으로 갈렸다. 대부분이 이관 강제 완료였고 나중에 옵션을 추가하면서 코드가 겹친 것이 몇 건이며 등록은 정상이었는데 그 뒤 옵션을 바꿔 불일치가 난 것이 몇 건이었다.
원인이 다르므로 대응도 다를 수 있다. 조치 전에 여러 축으로 쪼개 세는 것이 이 조사의 요지였는데 한 덩어리로 보면 한 가지 조치만 떠올리게 된다.
정리
- 조치하기 전에 여러 축으로 쪼개 센다
- 값이 없어서라는 가설은 대부분이 값을 가지고 있으면 무너진다
- 이관이 실제 호출 없이 강제 완료시켰으면 외부에는 옛 상태가 남는다
- 우리 쪽 값을 바꿔도 외부와 다르면 소용없다
- 맞추려면 한쪽을 다른 쪽에 맞춰야 한다
- 그 조치는 둘 다 외부를 건드린다
- 쪼개면 유형이 여럿이고 원인이 다르다
- 한 덩어리로 보면 한 조치만 떠올린다