agent-cron: 감시형 태스크의 의미 있는 exit 1이 'retry-exhausted' 고장으로 표시된다

[jinon86]

요약

fleet 감시 태스크는 이상을 발견하면 exit 1로 알리도록 설계돼 있다. 그런데 agent-cron은 nonzero exit을 모두 실행 실패로 간주해 lastStatus=failed → health=retry-exhausted로 표시한다.

그 결과 정상적으로 제 역할을 한 감시자가 "고장난 태스크"로 보인다.

실측 (곽가 / vps7, 2026-08-03)

agent-cron status:

id	health	last status	retry
adapter-fleet-watch	retry-exhausted	failed	exhausted
fleet-doctor-sweep	retry-exhausted	failed	exhausted

두 태스크 모두 scripts/fleet-bridge-watch.sh를 실행하는 command payload이고 retryPolicy: null이다.

실제 실행 내용은 정상 감시 결과였다:

adapter-fleet-watch  exitCode=1  → DOWN=1
  OK seoseo … OK gwakga  DOWN jingun  OK gongmyoung … (11/12 OK)

fleet-doctor-sweep   exitCode=1  → DRIFT=1
  OK seoseo … DRIFT yukson doctor_exit=1 runtime=/root/ccc-node … (11/12 OK)

알림도 정상 발송됐다 (telegram-spool/sent/에 4건 이상, notifyState: spooled).

재실행하니 상태가 바뀌어 있었다 — 감시자가 실시간 fleet 상태를 정확히 반영하고 있다는 뜻이다:

adapter-fleet-watch 재실행 → exit=0  (jingun 복구, 12/12 OK)
fleet-doctor-sweep  재실행 → exit=1  (yukson 해소, 대신 DRIFT dungae doctor_exit=1)

실행 이력도 간헐 패턴이다: 08-01 failed → 08-02 success → 08-03 failed. 스크립트 고장이 아니라 fleet 상태가 오간 것이다.

문제

1. 의미 구분 부재 — "태스크가 실행에 실패했다"와 "태스크가 성공적으로 실행되어 이상을 보고했다"가 모두 failed다.
2. retryPolicy: null인데 retry-exhausted — 재시도 정책이 없는데 retryState.lastStatus: "exhausted"가 기록되고 health가 retry-exhausted로 굳는다. 재시도 개념이 없는 태스크에 재시도 소진 상태를 부여하는 건 의미가 맞지 않는다.
3. 운영 판단 오염 — 상태 표만 보면 두 감시자가 며칠째 죽어 있는 것으로 읽힌다. 실제로 이번 조사에서 처음에 그렇게 오독했다. 진짜 고장이 섞여 들어와도 구분할 수 없다.

제안

1. 태스크 정의에 성공으로 볼 exit code 집합을 둔다. 예: --success-exit-codes 0,1 또는 감시형을 뜻하는 --kind watch(nonzero=findings). 그러면 exit 1은 success-with-findings로 분류하고, 진짜 실행 실패(스크립트 없음, 타임아웃, exit 2+)만 failed로 남는다.
2. retryPolicy가 없으면 retryState를 기록하지 않거나 health를 retry-exhausted가 아닌 값으로 표기한다.
3. status 출력에 lastExitCode를 노출해 운영자가 1(findings)과 127(실행 불가)을 구분할 수 있게 한다.
4. 알림 문구는 이미 fleet alert … DOWN=1 형태로 잘 구분되므로 그대로 두면 된다. 문제는 상태 표시다.

참고 — 이번 조사에서 함께 확인된 것

fleet-doctor-sweep가 현재 보고하는 DRIFT dungae는 실제로는 미머지 작업(#890 nunchi write-gate)의 로컬 선반영이었다. 설치본 4개가 레포본과 다르고 mtime이 모두 2026-08-03 14:42:34로 동일하며 최근 12커밋 어디와도 일치하지 않는다. ccc-doctor --fix --apply를 돌리면 이 미머지 작업이 덮인다. doctor 권고 문구가 정확히 그것을 지시하므로, DRIFT 판정에 "미머지 로컬 작업일 수 있음" 경고를 붙이는 것도 검토할 만하다.

---

근거: 곽가/vps7 실측, 2026-08-03 KST. 관련 #909, #910