접수됐다는 응답
복권 결과를 보여주는 서비스는 당첨 번호를 직접 가져오지 않는다. 따로 둔 수집 서비스가 번호를 모아 콜백으로 넘겨준다. 추첨이 끝나면 새 회차가 화면에 떠야 한다.
한번은 수집 요청을 보내고 HTTP 202를 받았다. 수집 API의 202는 비동기 작업을 접수했다는 응답이었다. 이후 수집 서비스의 실행·처리 결과를 열어보니 unsupported_source였다. 그 출처는 아직 지원하지 않는다는 뜻이었고, 실제로는 아무것도 수집되지 않았다.
성공을 네 번 나눠 확인한다
그 뒤로 "수집 성공"을 한 번에 판단하지 않는다.
- 추첨 뒤 정해진 시각에 수집이 실제로 돌았나?
- 그 출처의 데이터가 처리됐나?
- 결과 서비스가 콜백을 받아 저장했나?
- 화면에 보이는 회차와 날짜가 맞나?
수집 서비스와 결과 서비스가 따로 있어서 한쪽 로그만 봐서는 알 수 없다. 요청을 보냈는지, 수집이 끝났는지, 화면에서 확인했는지를 따로 적었다.
202는 이 흐름의 입구다. 뒤의 단계까지 완료됐다는 증거로 쓰지 않는다. 예를 들어 unsupported_source라면 콜백이나 화면을 기다리기 전에 수집 대상 지원 여부부터 확인해야 한다.
결과가 없을 때 나눌 질문
| 멈춘 지점 | 먼저 확인할 내용 |
|---|---|
| 실행 자체가 없음 | 예정한 수집 시각과 실제 실행 여부 |
| 실행했지만 데이터가 없음 | 출처 지원 여부와 처리 결과 |
| 수집됐지만 저장되지 않음 | 결과 서비스의 콜백 수신과 저장 여부 |
| 저장됐지만 화면이 다름 | 공개 결과의 회차와 날짜 |
이 표는 원인을 좁히는 순서다. 한 단계가 늦다고 바로 다음 단계의 문제로 단정하지 않기 위해 쓴다.
기다릴 일과 고칠 일을 구분하기
지원하지 않는 출처라면 기다려도 수집할 수 없다. 반면 지원하는 출처인데 원천에서 새 결과를 아직 게시하지 않았다면, 다음 확인을 기다릴 수 있다. 실제 연결 오류나 처리 실패는 다시 원인을 찾아야 한다. 셋을 모두 같은 실패로 묶으면 필요 없는 재시도나 알림이 생긴다.
수집 결과와 콜백 저장, 공개 화면을 나눠 적는 것도 이 때문이다. 앞 단계가 접수됐다는 응답을 뒤 단계의 완료로 사용하지 않는다. HTTP 202의 의미 역시 처리 완료를 보장하지 않는다.
어디서 멈췄는지부터
이렇게 나누니 문제가 났을 때 할 질문이 짧아졌다. 수집이 안 돈 건지, 전달이 늦은 건지, 화면 값이 틀린 건지부터 본다. 같은 요청을 무작정 다시 보내는 일도 줄었다.
나중에 새 복권 종류를 붙일 때도 화면에 최신 회차가 뜨는 걸 보고 나서야 끝냈다.