스케줄러 결과 계약과 안전한 실패 관측

스케줄러 작업이 예외를 던지지 않았다는 사실은 성공을 뜻하지 않는다. 내부에서 오류를 잡고 None, error, 처리 수, partial을 반환하는 작업이 섞이면 관제는 정상·빈 결과·부분 실패를 구분하지 못한다.

상태를 고정한다

작업 결과는 최소한 completed, empty, skipped, partial, retrying, failed 중 하나로 수렴한다. 처리 개수는 보조 지표이고, 상태가 완료인지가 먼저다. 예를 들어 Da2ari 운세는 12개 sign 묶음 중 일부만 생성되면 partial 또는 failed이며, 완전한 묶음만 skip한다.

실패 원문을 저장하지 않는다

외부 응답·URL·DSN·사용자 입력이 예외 문자열에 섞일 수 있다. 실패 테이블과 로그에는 status:partial, status:failed, exception:TimeoutError 같은 제한된 코드만 남기고, 원문은 반환 계약이나 사용자 응답으로 흘리지 않는다. 이 코드는 재시도 여부와 운영 화면의 필터에 충분하다.

완료 기준

• 예외·구조화 실패·부분 결과가 같은 scheduler failure 경로에 기록된다.
• 성공 수가 있어도 실패 범위가 있으면 성공으로만 관측되지 않는다.
• 실패 저장소가 내려가도 scheduler 자체는 다음 job을 계속 실행한다.
• 운영자는 job ID, 상태 코드, 재시도 범위를 조회할 수 있지만 민감한 원문은 볼 수 없다.

관련 강좌: 부분 실패·복구·플랫폼 경계를 교차 서비스 계약으로 닫기