한 채널에 SUSPEND 를 보냈는데 나중에 조회하면 sale_status 가 안 바뀌어 있었다. 보냈는데 안 바뀐다는 증상부터 경로를 그려 봤다.
Table of contents
Open Table of contents
배경 — 쓰기와 읽기의 두 경로
쓰기는 본체가 채널 API 의 PUT /products/{id}/status 를 직접 불러 상태를 바꾸는 경로였다. 읽기는 ProductCollector 가 내부 gateway 서비스를 거치고 그 서비스가 채널을 부른 뒤 자기 스키마로 변환해 돌려주는 경로였다.
두 경로가 같은 마켓을 향하지만 지나는 단계가 다르다. 같은 대상에 대해 쓰는 길과 읽는 길이 다르면 그 사이 어디서든 어긋날 수 있다.
원인 — 원본으로 오인한 필드
수집기 코드에서 상태를 꺼내는 sale_status 필드 이름을 보고 채널이 주는 값으로 읽었다. 실제로는 gateway 가 자기 형식으로 만든 응답의 필드였다.
필드명은 그 값이 어디서 왔는지를 알려 주지 않고 중간 서비스가 붙인 이름일 수 있다. 이름을 원본으로 오인한 것이 조사 방향을 한참 틀었다.
검증 — 값의 출처를 따라가는 네 단계
두 가지 방법이 있었는데 필드명이 같으니 채널 값으로 보고 채널에 문의하는 것과 출처를 끝까지 따라가는 것이다. 뒤쪽을 골랐다. 이유는 필드명은 그 값이 어디서 왔는지를 알려 주지 않아서다. 대신 저장소 셋을 오가며 반나절이 드는 것을 감수했다. 출처를 알려면 수집기의 필드에서 gateway 의 응답 스키마로 가고 거기서 그 서비스의 ChannelClient 코드로 가고 마지막으로 채널의 어느 경로를 부르는지까지 가야 했다. 네 단계를 거쳐야 원본이 나온다.
첫 단계에서 멈추면 그 이름이 원본으로 보인다. 쓰기가 바꾸는 값과 읽기가 보는 값이 서로 다른 경로의 값이면 그 자체가 불일치의 원인 후보가 된다.
주의 — 문서를 읽고도 반영 안 한 이유
조사 중에 수집기 저장소의 CONTRACT.md 에 gateway 를 경유한다고 적혀 있다는 지적을 받았다. 그 문서를 열긴 열었는데 조사에 반영하지 않았다.
수집기가 무엇을 읽는지 볼 때 코드부터 봤고 코드에 필드명이 있으니 그것이 답처럼 보였다. 문서의 경유한다는 문장은 배경 설명으로 흘려 봤는데 코드가 더 구체적으로 보인다는 것이 그 판단을 만들었다.
조치 — 확정 못 한 것을 남기기
쓰기와 읽기가 같은 채널 경로를 부르는지까지는 이번에 확정하지 못했다. 채널 쪽에도 GET /products/{id} 와 GET /products/{id}/status 처럼 상태를 볼 수 있는 경로가 여럿이라 서로 다른 경로일 가능성이 남아 있었다.
그래서 그 부분을 INVESTIGATION.md 에 후속 확인으로 남기고 확정한 것처럼 적지 않았다. 이 구조는 이 채널만의 문제가 아니라 중간 서비스를 경유하는 모든 채널에 같으므로 확인 순서를 규칙으로 적었다.
정리
- 쓰기 경로와 읽기 경로가 서로 다른 단계를 거칠 수 있다
- 같은 대상이어도 지나는 길이 다르면 어긋날 자리가 생긴다
- 수집기가 읽는 필드는 중간 서비스의 스키마일 수 있다
- 필드명은 값의 출처를 알려 주지 않는다
- 출처는 호출 스택을 거꾸로 끝까지 따라가야 나온다
- 쓰기와 읽기가 다른 경로를 부르면 그것이 원인 후보다
- 문서를 읽고도 반영 안 하는 것은 코드가 더 구체적으로 보이기 때문이다
- 확정 못 한 것은 후속 확인으로 남긴다