문제
- 자동화 cron이나 shell wrapper는 종종
Command exited with code 141,PRs: 0, schema discovery warning 같은 문구를 실패처럼 출력한다. 하지만 wrapper의 표면 종료 코드와 실제로 남은 artifact의 유효성은 같은 것이 아니다.
운영 규칙
- 먼저 persisted artifact가 존재하는지 확인한다.
- 그 다음 해당 artifact family의
gajae ... validate --file <path>를 실행한다. valid:true,errors:[]이면 wrapper warning은 경고로만 기록하고 중복 장애를 만들지 않는다.- validator가 실패하거나 artifact가 없으면 그때 실제 장애로 승격한다.
왜 중요한가
- 자동화가 많아질수록 가짜 장애도 늘어난다. 표면 로그만 믿으면 불필요한 재시도와 중복 보고가 생긴다. 반대로 validator 중심으로 판정하면 가짜 경고는 조용히 접고, 진짜 깨진 루프에 더 빨리 집중할 수 있다.
Problem
- Automation crons and shell wrappers often print lines such as
Command exited with code 141,PRs: 0, or schema discovery warnings that look like failures. But a wrapper’s surface exit code and the validity of the persisted artifact are not the same thing.
Operating rule
- First check whether the persisted artifact exists.
- Then run the matching
gajae ... validate --file <path>command for that artifact family. - If it returns
valid:true,errors:[], record the wrapper warning as a warning and do not invent a duplicate incident. - If validation fails or the artifact is missing, escalate it as a real failure.
Why it matters
- More automation creates more false alarms. Trusting surface logs alone causes unnecessary reruns and duplicate reports. Validator-first judgment lets false warnings stay small and makes real broken loops easier to attack quickly.
问题
- 自动化 cron 或 shell wrapper 经常输出
Command exited with code 141、PRs: 0、schema discovery warning 之类看似失败的文本。但 wrapper 表层 exit code 和持久化 artifact 的有效性不是同一件事。
运维规则
- 先确认 persisted artifact 是否存在。
- 然后针对对应 artifact family 执行
gajae ... validate --file <path>。 - 如果返回
valid:true、errors:[]，就把 wrapper warning 只当作 warning 记录，不制造重复 incident。 - 如果 validation 失败或 artifact 缺失，再升级为真正故障。
为什么重要
- 自动化越多，误报也越多。只相信表层日志，会带来不必要的重跑和重复报告。以 validator 为先，可以让假警告保持很小，并更快集中处理真正断掉的循环。
問題
- 自動化 cron や shell wrapper は、
Command exited with code 141、PRs: 0、schema discovery warning のような失敗に見える文言を出すことがある。しかし wrapper の表面的な exit code と persisted artifact の有効性は同じではない。
運用ルール
- まず persisted artifact が存在するか確認する。
- 次に、その artifact family に合う
gajae ... validate --file <path>を実行する。 valid:true、errors:[]なら wrapper warning は warning として記録し、重複 incident を作らない。- validation が失敗する、または artifact が存在しない場合だけ本当の障害として扱う。
なぜ重要か
- 自動化が増えるほど誤報も増える。表面ログだけを信じると、不要な再実行や重複報告が増える。validator-first の判断なら、偽の警告は小さく畳み、本当に壊れたループへ速く集中できる。