왜
터미널 FAILED 로 끝난 파싱 행을 운영자가 모아 보거나 일괄 재처리할 경로가 없다.
현재 실패 후 벌어지는 일은 이게 전부다.
ItemParsingFailed 이벤트 → SSE 알림으로 그 사용자에게 통지- 사용자 개인이
recoverWishItem(손으로 값 채워 READY) 또는 refreshWishItem(새 snapshot 생성)으로 직접 복구
- 메트릭(
item.parsing{result=failed,reason=*})은 빈도만 보여준다 — "어떤 행이" 실패했는지 목록이 없다
즉 사용자가 알아서 다시 시도하지 않으면 그 아이템은 실패한 채로 남는다.
특히 #802 가 도입한 마감 종결(reason=deadline)은 사용자 입력이 잘못된 게 아니라 우리 용량이 부족했던 것이다. 슬롯이 3분 안에 나지 않아 실행을 한 번도 못 한 행까지 FAILED 로 끝나는데, 그걸 사용자가 알아서 재시도하기를 기다리는 건 부적절하다. retry_exhausted(일시 오류가 상한까지 반복)도 마찬가지로 우리 쪽 사정이다.
무엇을
종결 사유별로 재처리 가치가 있는 실패를 골라내 운영자가 조회·일괄 재처리할 수 있게 한다.
- 저장 방식 결정: 별도 DLQ 테이블 vs 기존
item_snapshots 조회(status=FAILED + 사유)
- 관건: 종결 사유(reason)가 현재 메트릭 라벨에만 있고 행에는 저장되지 않는다. 어느 쪽을 택하든 사유를 행에 남기는 작업이 선행돼야 한다.
- 재처리 대상 판정
- 가치 있음:
deadline(용량 부족) · retry_exhausted(일시 오류 반복) · no_source(영속화 경로 결함 신호)
- 무의미:
not_product(상품 페이지 아님) · permanent_error(호스트 차단 등) · ready_rejected(추출값 부적격)
- 어드민 백오피스 조회 화면
- 일괄 재처리 진입점(새 PENDING snapshot 생성 → 기존 작업 큐 흐름에 태움)
- 재처리 시 사용자 알림을 다시 보낼지 여부 검토(이미 실패 알림을 받은 사용자에게 성공 알림이 뒤늦게 가는 것이 자연스러운가)
관련: #802 (마감 종결 도입) · #461 (execution at-least-once) · #506 (파싱 결과 메트릭)
왜
터미널
FAILED로 끝난 파싱 행을 운영자가 모아 보거나 일괄 재처리할 경로가 없다.현재 실패 후 벌어지는 일은 이게 전부다.
ItemParsingFailed이벤트 → SSE 알림으로 그 사용자에게 통지recoverWishItem(손으로 값 채워 READY) 또는refreshWishItem(새 snapshot 생성)으로 직접 복구item.parsing{result=failed,reason=*})은 빈도만 보여준다 — "어떤 행이" 실패했는지 목록이 없다즉 사용자가 알아서 다시 시도하지 않으면 그 아이템은 실패한 채로 남는다.
특히 #802 가 도입한 마감 종결(
reason=deadline)은 사용자 입력이 잘못된 게 아니라 우리 용량이 부족했던 것이다. 슬롯이 3분 안에 나지 않아 실행을 한 번도 못 한 행까지 FAILED 로 끝나는데, 그걸 사용자가 알아서 재시도하기를 기다리는 건 부적절하다.retry_exhausted(일시 오류가 상한까지 반복)도 마찬가지로 우리 쪽 사정이다.무엇을
종결 사유별로 재처리 가치가 있는 실패를 골라내 운영자가 조회·일괄 재처리할 수 있게 한다.
item_snapshots조회(status=FAILED+ 사유)deadline(용량 부족) ·retry_exhausted(일시 오류 반복) ·no_source(영속화 경로 결함 신호)not_product(상품 페이지 아님) ·permanent_error(호스트 차단 등) ·ready_rejected(추출값 부적격)관련: #802 (마감 종결 도입) · #461 (execution at-least-once) · #506 (파싱 결과 메트릭)