partner_fees 설정을 고쳤는데도 여전히 실패한다는 얘기가 있었다. 화면에는 실패가 스물몇 건인데 왜 백 건 넘게라고 하느냐는 지적도 함께 왔다.
Table of contents
Open Table of contents
원인 — 조회 축의 불일치
내가 센 쿼리는 status != 'completed' 이고 last_error 에 특정 문구가 든 것을 전부 세고 있었다. 화면은 스물몇 건이고 내 결과는 백 건 넘게로 몇 배 차이였다.
코드 문제인가 싶었지만 그 전에 조회 축을 봤다. DATE(updated_at) = CURDATE() 로 좁히니 화면과 같은 건수가 나왔다. 내 쿼리가 과거 누적분까지 세고 있었던 것이다. 건수 불일치는 코드 문제로 보기 전에 조회 축부터 맞춰야 하고 created_at 과 updated_at 과 attempts 와 날짜 범위가 전부 축 후보다.
주의 — 맞춘 것과 확인한 것
여기서 밝혀 둘 것이 있다. 화면 쿼리의 명세를 확인한 것이 아니라 건수가 일치하는 것을 보고 역산한 추정이다.
우연히 일치했을 수도 있고 다른 조건 조합이 같은 숫자를 낼 수도 있다. 그래서 기록에 건수 일치로 역산한 추정이며 명세를 확인한 것은 아니라고 적었다. 맞춘 것과 확인한 것은 다르다.
로그가 가리키는 시점
추정이 아닌 확정 사실이 따로 나왔고 그것이 더 중요했다. last_error 와 updated_at 은 마지막 재시도 시점의 결과이고 데이터를 고쳐도 실패 레코드는 지워지지 않는다.
낮에 재시도해서 실패한 기록이 남아 있고 오후에 데이터를 고쳤다면 그 뒤에 조회해도 여전히 실패로 보인다. 수정 이후 재시도가 없었으므로 안 바뀌는 것이 당연했고 고친 것이 안 먹은 것이 아니라 고친 뒤로 아직 시도를 안 한 것이었다.
검증 — 실측으로 확인한 판정
건별로 확인하니 그 열몇 건 전부 updated_at 이 수정 시각보다 앞서 있었다. 두 가지 방법이 있었는데 다음 정기 재시도를 기다리는 것과 jobs:retry 로 그 건만 지금 돌리는 것이다. 뒤쪽을 골랐다. 이유는 판정에 필요한 것이 수정 이후의 시도 한 번이라서다. 대신 정기 재시도가 잡았을 다른 실패까지 섞여 들어오지 않게 --ids 로 대상을 한정하는 수고를 감수했다. 실제로 재시도를 돌리니 전량 성공했다.
여기서 규칙이 나왔는데 수정 효과 판정은 수정 시각 이후의 재시도분으로만 한다는 것이다. 그보다 이전 타임스탬프의 실패는 판정 근거가 될 수 없다. 이것을 안 하면 고쳤는데 안 됐다고 오판하고 다른 원인을 찾느라 시간을 쓰거나 고친 것을 되돌리는데 맞는 수정을 틀렸다고 되돌리는 것이 가장 나쁘다.
상태와 이력의 구분
열몇 건이 해결되고 남은 것들은 같은 원인인지 다른 원인인지를 갈라야 했다. supplier_id 별로 나눠 각각 설정 상태를 확인하기로 하고 뭉뚱그려 나머지로 두지 않았다.
실패 레코드가 지워지지 않고 남는 구조 자체는 나쁘지 않고 이력이 필요하다. 문제는 그것이 현재 상태처럼 조회된다는 점인데 status != 'completed' 조건과 last_error 가 합쳐지면 지금 실패 상태로 읽힌다. 실제로는 과거에 실패했고 그 뒤로 시도하지 않은 것이므로 시각 컬럼이 상태와 이력을 가르는 역할을 하지만 안 보면 소용이 없다.
정리
- 화면과 데이터베이스의 건수가 다르면 조회 축부터 맞춘다
- 축 후보는
created_at과updated_at과attempts와 날짜 범위다 - 건수를 맞춘 것과 명세를 확인한 것은 다르다
- 역산으로 얻은 것은 추정이라고 적는다
last_error와updated_at은 마지막 재시도 시점의 결과다- 데이터를 고쳐도 실패 레코드는 안 지워진다
- 수정 효과는 수정 시각 이후의 재시도분으로만 판정한다
- 맞는 수정을 틀렸다고 되돌리는 것이 가장 나쁘다