같은 거부의 두 원인

신분증 확인을 외부 업체 API 에 맡기는데 이미지 규격 거부가 계속 났고 오류 메시지가 전부 같았다. 같은 문제로 보고 한 곳을 고쳤더니 일부만 해결됐다.

Open Table of contents

배경 — 같은 메시지 아래 두 부류

우리는 이미지를 직접 보내지 않고 kyc_requests.image_url 에 든 주소를 넘긴다. 상대가 그 주소를 받아 가고 못 받으면 INVALID_IMAGE 하나로 거부한다.

해결된 것과 안 된 것의 요청 내용을 비교하니 달랐다. 한쪽은 주소에 사용자가 올린 원본 파일명의 한글이 인코딩 안 된 채로 들어가 주소 자체가 무효였다.

다른 쪽은 주소는 정상인데 그 위치에 파일이 없었다. ImageResizeJob 이 thumb_ 변환본을 아직 안 만든 시점에 전송된 것이었다.

앞의 부류는 주소를 만드는 코드에 URLEncoder.encode 를 UTF-8 로 넣으면 끝난다. URI 가 US-ASCII 문자 집합으로 이뤄지고 그 밖의 문자는 퍼센트 인코딩으로 적는다는 것은 RFC 3986 이 정한다.

뒤의 부류는 타이밍 문제라 변환이 끝난 뒤에 보내도록 순서를 보장하거나 재시도를 붙여야 한다. 한 곳만 고쳐서는 다른 부류가 그대로 남는다. 증상이 같아도 고치는 자리가 다르면 그것은 하나의 문제가 아니다.

이것을 알고 나서 고치기 전에 분류부터 했다. image_url 에 비아스키 문자가 있는지로 갈라서 세니 두 부류의 비율이 나왔다.

이 숫자가 있으니 어느 쪽부터 할지가 정해진다. 인코딩 쪽을 먼저 골랐다. 이유는 코드 한 줄이고 그 부류가 더 많아서다.

그리고 각각을 고친 뒤에 그 부류만 줄었는지를 따로 확인할 수 있다. 대신 타이밍 부류는 며칠 더 거부가 쌓이는 것을 감수했다.

인코딩을 고치고 실패 건을 다시 보내니 한 부류가 통과했다. 그 시점에 해결됐다고 보고할 수 있었다. 나머지 부류는 그대로였으므로 며칠 뒤에 아직 안 된다는 말이 왔을 것이다.

부분 해결을 전체 해결로 보고하면 이미 고쳤다는 기록이 남아서 남은 것을 다시 조사할 때 그쪽부터 의심하지 않게 된다. 그래서 부류별 건수와 각각의 상태와 남은 작업 일정을 나눠 적었다.

이 분류를 매번 손으로 하기 번거로워서 실패 목록 조회에 error_class 컬럼을 넣었다. 상대가 보낸 INVALID_IMAGE 가 그대로 찍혀 있어도 우리가 붙인 부류가 함께 보인다.

새 실패가 들어오면 어느 쪽인지 바로 알 수 있다. 기존 분류 어디에도 안 걸리는 것이 나타나면 그것 자체가 새 부류가 생겼다는 신호가 된다.