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