네 코인이 출금 중지와 전송 실패로 CS 에 접수됐고 그 상태의 관리 화면 캡처가 첨부돼 있었다. 두 가지 방법이 있었다. 코인을 하나씩 따로 조회하는 것과, coin_master 에 broadcast_jobs 를 붙여 한 쿼리로 묶어서 함께 보는 것이다. 뒤쪽을 골랐다. 이유는 코인마다 따로 조회하면 그 차이를 머릿속에서 비교하는 수밖에 없어서다. 대신 조인 조건을 맞추느라 쿼리 하나에 십 분을 더 쓰는 것을 감수했다.
Table of contents
Open Table of contents
조사 — 네 코인을 한 쿼리로
coin_master 의 wallet_status 와 broadcast_jobs 의 미완료 작업을 LEFT JOIN 으로 함께 붙였다. 한 번에 표로 나오게 하니 네 코인이 두 그룹으로 갈리는 것이 바로 보였다.
각각 봤으면 서로 다른 원인이라는 것을 알아채는 데 더 걸렸을 것이다.
검증 — 두 그룹으로 갈린 결과
그중 두 코인은 wallet_status 가 SUSPENDED 였고 미완료 작업이 아예 없었다. 나머지 둘은 ACTIVE 였고 전송 작업이 DONE 으로 남아 있었다.
앞의 둘은 상태 자체가 막고 있는 것이었고 뒤의 둘은 이미 정상 상태였다. 같은 이슈로 접수됐지만 원인도 조치도 다른 두 건이 섞여 있었다.
원인 — 상태 코드가 작업 생성을 막는다
BroadcastJobFactory 를 열어 보니 SUSPENDED 이면 모든 작업 생성을 거부하고 있었다. 그러면 출금 승인을 누르든 재전송을 누르든 작업 자체가 안 만들어진다.
실행이 실패하는 것이 아니라 실행 대상이 생기지 않는 것이라 재시도로는 풀리지 않는다. 이 경우 대응은 재시도가 아니라 지갑 점검을 끝내고 ACTIVE 로 되돌리는 다른 흐름이었다.
캡처와 데이터의 시점 차이
나머지 두 코인은 캡처에는 FAILED 로 나와 있는데 지금 조회하면 DONE 이었다. 접수부터 조사까지 사이에 재시도가 성공한 것이었다.
캡처는 찍은 시점의 화면이고 데이터는 지금 상태다. 캡처를 그대로 믿었으면 이미 정상인 것을 미해결로 보고 조사했을 것이다.
미완료만 붙인 조인
조회할 때 status <> 'DONE' 인 작업만 조인한 것이 결과 표를 읽기 좋게 만들었다. 완료된 것까지 붙이면 행이 수십 개가 되어 지금 막혀 있는 것이 안 보인다.
LEFT JOIN 으로 붙였으므로 작업이 없는 코인도 행이 나온다. 작업이 하나도 없다는 것 자체가 상태가 막고 있다는 신호였다.
정리
SUSPENDED같은 상태 코드가 모든 작업 생성을 차단할 수 있다- 그러면 실행 실패가 아니라 실행 대상이 안 생긴다
- 재시도로는 안 풀리고 다른 흐름으로 가야 한다
- 중지로 접수되면 실행 실패보다
wallet_status부터 확인한다 - 캡처와 데이터가 어긋날 수 있고 시점이 다르기 때문이다
- 캡처는 그때 그랬다는 증거이지 지금의 증거가 아니다
- 여러 대상을 한 쿼리로 묶으면 그룹이 한눈에 보인다
- 미완료만
LEFT JOIN으로 붙이면 없는 것도 신호가 된다