수수료 설정을 고쳤는데도 여전히 실패한다는 얘기가 있었다. 화면에는 실패가 25건인데 왜 179건이라고 하느냐는 지적도 함께 왔다.
Table of contents
Open Table of contents
조회 축의 불일치
내가 센 쿼리는 완료되지 않았고 로그에 특정 문구가 든 것을 전부 세고 있었다. 화면은 25건이고 내 결과는 179건으로 일곱 배 차이였다.
코드 문제인가 싶었지만 그 전에 조회 축을 봤다. 갱신 시각이 오늘인 것으로 좁히니 화면과 같은 25건이 나왔다. 내 쿼리가 과거 누적분까지 세고 있었던 것이다. 건수 불일치는 코드 문제로 보기 전에 조회 축부터 맞춰야 하고 생성 시각과 갱신 시각과 시도 횟수와 날짜 범위가 전부 축 후보다.
맞춘 것과 확인한 것
여기서 밝혀 둘 것이 있다. 화면 쿼리의 명세를 확인한 것이 아니라 건수가 일치하는 것을 보고 역산한 추정이다.
우연히 일치했을 수도 있고 다른 조건 조합이 같은 숫자를 낼 수도 있다. 그래서 기록에 건수 일치로 역산한 추정이며 명세를 확인한 것은 아니라고 적었다. 맞춘 것과 확인한 것은 다르다.
로그가 가리키는 시점
추정이 아닌 확정 사실이 따로 나왔고 그것이 더 중요했다. 로그와 갱신 시각은 마지막 재시도 시점의 결과이고 데이터를 고쳐도 실패 레코드는 지워지지 않는다.
낮에 재시도해서 실패한 기록이 남아 있고 오후에 데이터를 고쳤다면 그 뒤에 조회해도 여전히 실패로 보인다. 수정 이후 재시도가 없었으므로 안 바뀌는 것이 당연했고 고친 것이 안 먹은 것이 아니라 고친 뒤로 아직 시도를 안 한 것이었다.
실측으로 확인한 판정
건별로 확인하니 18건 전부 갱신 시각이 수정 시각보다 앞서 있었다. 실제로 재시도를 돌리니 전량 성공했다.
여기서 규칙이 나왔는데 수정 효과 판정은 수정 시각 이후의 재시도분으로만 한다는 것이다. 그보다 이전 타임스탬프의 실패는 판정 근거가 될 수 없다. 이것을 안 하면 고쳤는데 안 됐다고 오판하고 다른 원인을 찾느라 시간을 쓰거나 고친 것을 되돌리는데 맞는 수정을 틀렸다고 되돌리는 것이 가장 나쁘다.
상태와 이력의 구분
18건이 해결되고 남은 것들은 같은 원인인지 다른 원인인지를 갈라야 했다. 공급사별로 나눠 각각 설정 상태를 확인하기로 하고 뭉뚱그려 나머지로 두지 않았다.
실패 레코드가 지워지지 않고 남는 구조 자체는 나쁘지 않고 이력이 필요하다. 문제는 그것이 현재 상태처럼 조회된다는 점인데 완료되지 않았다는 조건과 실패 로그가 합쳐지면 지금 실패 상태로 읽힌다. 실제로는 과거에 실패했고 그 뒤로 시도하지 않은 것이므로 시각 컬럼이 상태와 이력을 가르는 역할을 하지만 안 보면 소용이 없다.
정리
- 화면과 데이터베이스의 건수가 다르면 조회 축부터 맞춘다
- 축 후보는 생성 시각과 갱신 시각과 시도 횟수와 날짜 범위다
- 건수를 맞춘 것과 명세를 확인한 것은 다르다
- 역산으로 얻은 것은 추정이라고 적는다
- 로그와 갱신 시각은 마지막 재시도 시점의 결과다
- 데이터를 고쳐도 실패 레코드는 안 지워진다
- 수정 효과는 수정 시각 이후의 재시도분으로만 판정한다
- 맞는 수정을 틀렸다고 되돌리는 것이 가장 나쁘다