승인 상태가 막혀 있던 코인 출금 요청을 노드 재조회로 교정했다. 일부가 approval_status = 'APPROVED' 로 바뀌었다. 그런데 그중 열두 건에서 노드 전송 작업 broadcast_jobs 가 만들어지지 않았다.
Table of contents
Open Table of contents
증상 — 승인은 됐는데 작업이 안 생긴 건
withdrawals 를 조회하니 APPROVED 로 바뀌어 있었다. 그러면 broadcast_jobs 에 행이 생겨야 하는데 아무것도 없었다.
작업 생성을 막는 조건이 무엇인지부터 후보를 세웠다. 수수료 잔액 fee_balance 부족과 1일 한도 daily_limit 초과와 회원 활성 여부와 otp_verified 플래그 넷이 그럴듯했다.
검증 — 네 가설을 하나씩 배제한 뒤
해당 건들의 fee_balance 를 조회하니 전부 충분해서 그 조건에 안 걸렸다. 금액도 daily_limit 이내였고 회원은 활성이었으며 otp_verified 도 전부 참이었다.
넷이 전부 배제되고 나서 BroadcastJobFactory 의 차단 지점을 처음부터 다시 읽었다. 거기서 보는 것이 승인 상태가 아니라 회원 계정의 출금 잠금 상태 withdraw_locked 였다.
원인 — 승인 상태와 잠금 상태
열두 건의 회원을 조회하니 전부 withdraw_locked = 'Y' 이거나 status = 'SUSPENDED' 였다. 수사 협조로 잠근 계정과 정지된 계정이었다. 승인 상태와 잠금 상태가 독립된 두 축이었던 것이다.
노드 재조회는 승인 상태만 갱신하고 잠금 상태는 건드리지 않는다. 한쪽이 정상으로 돌아왔다고 다른 쪽이 따라오지는 않는다.
차단이 정상 방어였다
처음에는 작업이 안 생기는 것을 결함으로 봤는데 잠긴 계정의 코인을 밖으로 안 보내는 방어였다. 고칠 대상이 아니라 지켜야 할 동작이었다.
두 가지 길이 있었다. 열두 건을 손으로 broadcast_jobs 에 넣어 문의를 닫는 것과, 그대로 두고 CS 답변을 잠금 안내로 바꾸는 것이다. 뒤쪽을 골랐다. 이유는 잠금은 수사기관 요청으로 건 것이라 풀 권한이 우리에게 없어서다. 대신 회원이 승인 완료 표시를 보며 기다리는 것을 감수했다. 그 표시에는 잠금 안내가 붙게 했다. 강제로 작업을 만들었으면 잠근 계정의 코인이 밖으로 나갔을 것이다. 그래서 승인 상태가 정상인데 전송이 안 되면 withdraw_locked 부터 확인한다는 순서를 절차에 적었다.
전수 일치와 양쪽 대조
네 가설을 배제한 것의 값은 시간을 줄인 데 있지 않았다. 배제하지 않았으면 계정 상태 때문인 것 같다는 말까지만 할 수 있다. 다른 원인이 섞였을 가능성이 남는다.
열두 건 중 열두 건이 전부 같은 조건에 걸린 것도 단일 원인의 근거가 됐다. 코드에서 차단 조건을 찾고 데이터에서 그 조건에 걸리는지를 확인한다. 양쪽을 맞춰야 원인이라고 말할 수 있다.
정리
- 승인 상태와 잠금 상태가 독립된 두 축일 수 있다
- 한쪽 갱신이 다른 쪽을 안 건드린다
- 한쪽이 정상인데 안 되면
withdraw_locked같은 다른 축부터 확인한다 - 가설을 전부 배제하면 다른 원인이 섞일 가능성이 없어진다
- 대상 전부가 같은 조건에 걸리면 단일 원인이 확정된다
- 코드의 조건과 데이터의 상태를 맞춰야 원인이라고 말할 수 있다
- 차단이 정상 방어 로직일 수 있다
- 그것을 우회하면 잠근 계정의 코인이 나가는 오작동이 된다