코인 입금이 반영되지 않는다고 해서 노드 이벤트가 수집됐는지부터 확인했다. wallet_events 를 우리 deposits.id 로 조회했더니 아무것도 안 나왔다.
Table of contents
Open Table of contents
원인 — 우리 id 가 아니던 연결 키
테이블 정의를 열어 보니 deposit_ref 컬럼에 들어가는 값이 우리 내부 식별자가 아니었다. 노드가 부여한 txid 가 그 자리에 들어가고 있었다.
컬럼 이름이 우리 쪽 키를 뜻하는 것처럼 보여서 그대로 조회한 것이 문제였다. txid 로 다시 조회하니 두 건이 나왔다.
증상 — 비어 있던 오류 로그
두 건 중 앞의 입금은 CONFIRMED 이고 뒤의 입금이 ERROR 상태로 며칠째 멈춰 있었다. 사유를 보려고 error_message 컬럼을 열었더니 값이 비어 있었다.
실패했다는 것만 있고 왜 실패했는지가 없는 상태였다. 직접 근거가 없으므로 주변 상태 데이터로 추론하는 수밖에 없었다.
앞 상태가 막고 있었다
같은 입금 주소의 상태를 조회하니 앞의 입금이 의심 입금으로 REVIEW 검토 중이었다. 같은 주소 위에 검토가 진행 중인데 다음 입금을 생성하려던 상황이었다.
검토가 진행 중인 주소는 다음 입금 생성이 막히는 구조로 보였고 두 사실이 나란히 있는 것이 그 근거였다. 다만 로그가 비어 있어 코드로 확정한 것은 아니었다.
조치 — 수집과 생성의 구분
이런 경우 노드 재스캔으로 이벤트 수집을 다시 돌리는 대응이 흔한데 여기서는 안 된다. 수집은 이미 성공해서 wallet_events 에 레코드가 있고 실패한 것은 deposits 생성 단계였다.
두 가지 방법이 있었다. 막힌 입금을 관리 화면에서 손으로 만들어 넣는 것과, 앞의 검토를 먼저 종결해 주소 상태를 정리한 뒤에 수집된 이벤트를 재처리하는 것이다. 뒤쪽을 골랐다. 이유는 손으로 만들면 wallet_events 와 deposits 의 짝이 안 맞아 다음 대사에서 또 걸려서다. 대신 검토 종결까지 회원이 하루 더 기다리는 것을 감수했다.
부가 필드와 추정 표기
같은 레코드의 meta 필드를 열어 보니 auto_credit_at 이 들어 있었다. 검토가 끝나면 잔고 반영을 자동으로 한다는 뜻이므로 우리가 잔고까지 손으로 넣으면 이중 반영이 된다.
기록할 때는 조회로 확인한 두 사실과 검토 충돌이 원인이라는 정황 추정을 나눠 적었다. 추정을 확정으로 적으면 다음에 같은 오류를 볼 때 검토가 없는 경우가 조사에서 배제된다.
정리
- 연결 키가 우리 식별자가 아니라 노드의
txid일 수 있다 - 컬럼 이름이 어느 쪽 키인지를 말해 주지 않는다
error_message가 비어 있으면 주변 상태 데이터로 추론한다- 앞선 검토가 진행 중이면 다음 생성이 막힐 수 있다
- 수집과 생성을 갈라야 무엇을 다시 돌릴지가 정해진다
- 수동 생성보다 상태를 되돌려 재처리하는 편이 대사에 안전하다
meta필드에 자동으로 되는 일의 단서가 있다- 추정을 확정으로 적으면 다음 조사의 시야가 좁아진다