반품 건 하나의 수거 송장을 맞춰야 했고 넣을 값은 이미 알고 있었다. 남은 판단은 데이터베이스에 그 값을 그냥 넣으면 되는지였다.
Table of contents
Open Table of contents
기록처럼 보이는 이름
컬럼 이름만 보면 반품 테이블에 있는 수거 송장 번호이므로 기록용으로 읽힌다. 값을 넣어 두고 화면에 보여 주는 용도라면 갱신 한 줄로 끝나는 일이다.
그래도 넣기 전에 그 컬럼을 쓰는 곳을 저장소 전체에서 찾아봤다. 조회와 화면과 내보내기 정도가 나올 것이라고 예상하고 있었다.
전송 지점의 발견
예상과 달리 각 채널 처리기에서 그 값을 외부로 보내고 있었다. 채널마다 필드 이름은 달랐지만 전부 마켓 요청 본문에 실려 나가는 값이었다.
기록이 아니라 전송 대상이었다. 같은 파일 아래쪽에는 반대 방향도 있었는데 마켓이 회수 송장을 먼저 잡아 내려주면 그 값을 받아 저장하고 있었다. 우리가 보내기도 하고 받기도 하는 양방향 컬럼이었다.
반쪽이 되는 직접 갱신
여기까지 오면 직접 갱신이 무엇을 하고 무엇을 안 하는지가 분명해진다. 우리 데이터베이스 기록과 화면 표시는 맞지만 마켓으로 나가는 전송이 빠진다.
마켓은 여전히 송장을 모르는데 우리 화면에서만 맞아 보인다. 틀린 것을 맞다고 믿게 만드는 상태이므로 아무것도 안 한 것보다 나쁘다.
두 경우의 분기
그래서 상황을 두 경우로 갈라서 봤다. 아직 마켓 클레임이 열려 있는 진행 중인 반품은 정식 경로로 처리해야 저장과 전송이 같이 일어난다.
마켓 쪽 클레임이 완료로 닫힌 반품은 재전송 창이 닫혀서 보내도 받아 주지 않는다. 이 경우에만 직접 기록으로 정합이 완성되며 우리 쪽 기록만 비어 있는 상태를 채우는 일이 된다. 그쪽으로 가려면 클레임 상태를 조회해 정말 닫혔는지를 먼저 확인해야 한다.
조작 수단의 순서와 판별표
이 건에서 조작 수단에 대한 원칙 하나가 다시 확인됐다. API가 있으면 API로 하고 없으면 화면으로 하며 둘 다 없을 때만 직접 조작으로 내려가되 내려가기 전에 위 수단이 없다는 것을 확인해야 한다.
여기서는 정식 경로가 있는데 창이 닫혀서 못 쓴다는 것까지 확인한 뒤에 직접 기록으로 갔다. 판별 방법도 정했는데 값을 넣기 전에 그 컬럼의 사용처를 전부 찾아 조회와 화면만이면 순수 기록이고 외부 전송에 실리면 정식 경로로 가며 외부에서 받아 저장하면 양방향이라 직접 넣어도 다음 수신에 밀린다.
정리
- 기록처럼 보이는 컬럼이 외부로 전송되는 값일 수 있다
- 같은 컬럼이 양방향일 수 있다
- 직접 갱신은 기록만 되고 전송은 누락된다
- 화면에서만 맞아 보이는 상태가 아무것도 안 한 것보다 나쁘다
- 진행 중이면 정식 경로로 하고 종결된 건만 직접 기록한다
- 재전송 창이 닫혔는지 확인하고 내려간다
- 조작은 API와 화면과 직접 조작 순으로 하고 위가 없음을 확인한다
- 값을 넣기 전에 그 컬럼의 사용처를 전부 찾는다