쓰는 길과 읽는 길이 다르다

한 채널에 판매 중지를 보냈는데 나중에 조회하면 상태가 안 바뀌어 있었다. 보냈는데 안 바뀐다는 증상부터 경로를 그려 봤다.

Open Table of contents

쓰기와 읽기의 두 경로

쓰기는 본체가 마켓 인터페이스를 직접 불러 상태를 바꾸는 경로였다. 읽기는 수집기가 내부 인터페이스 서비스를 거치고 그 서비스가 마켓을 부른 뒤 자기 스키마로 변환해 돌려주는 경로였다.

두 경로가 같은 마켓을 향하지만 지나는 단계가 다르다. 같은 대상에 대해 쓰는 길과 읽는 길이 다르면 그 사이 어디서든 어긋날 수 있다.

수집기 코드에서 상태를 꺼내는 필드 이름을 보고 마켓이 주는 값으로 읽었다. 실제로는 중간 서비스가 자기 형식으로 만든 응답의 필드였다.

필드명은 그 값이 어디서 왔는지를 알려 주지 않고 중간 서비스가 붙인 이름일 수 있다. 이름을 원본으로 오인한 것이 조사 방향을 한참 틀었다.

출처를 알려면 수집기의 필드에서 내부 인터페이스의 응답 스키마로 가고 거기서 그 서비스의 채널 클라이언트 코드로 가고 마지막으로 마켓의 어느 경로를 부르는지까지 가야 했다. 네 단계를 거쳐야 원본이 나온다.

첫 단계에서 멈추면 그 이름이 원본으로 보인다. 쓰기가 바꾸는 값과 읽기가 보는 값이 서로 다른 경로의 값이면 그 자체가 불일치의 원인 후보가 된다.

조사 중에 수집기 저장소의 계약 문서에 내부 인터페이스를 경유한다고 적혀 있다는 지적을 받았다. 그 문서를 열긴 열었는데 조사에 반영하지 않았다.

수집기가 무엇을 읽는지 볼 때 코드부터 봤고 코드에 필드명이 있으니 그것이 답처럼 보였다. 문서의 경유한다는 문장은 배경 설명으로 흘려 봤는데 코드가 더 구체적으로 보인다는 것이 그 판단을 만들었다.

쓰기와 읽기가 같은 마켓 경로를 부르는지까지는 이번에 확정하지 못했다. 마켓 쪽에도 상태를 볼 수 있는 경로가 여럿이라 서로 다른 경로일 가능성이 남아 있었다.

그래서 그 부분을 후속 확인으로 남기고 확정한 것처럼 적지 않았다. 이 구조는 이 채널만의 문제가 아니라 중간 서비스를 경유하는 모든 채널에 같으므로 확인 순서를 규칙으로 적었다.