自动检测并恢复因网络故障失败的定时任务，在连接恢复时智能重试，确保关键作业可靠执行。
说明：
## 核心用法
Cron Retry 是一项自动化运维技能，专门解决定时任务（cron jobs）因网络瞬时故障而失败的问题。它通过与心跳（Heartbeat）系统集成，定期检查所有 cron 任务的状态，识别因网络错误（如连接超时、DNS 解析失败、消息发送失败等）而标记为 error 的任务，并在网络恢复后自动重试运行。
主要使用场景包括：
– **集成心跳监控**：在 `HEARTBEAT.md` 中添加 Cron Recovery Check 指令，实现无人值守的自动恢复
– **手动故障排查**：通过 `clawdbot cron list` 查看所有任务状态，结合 `jq` 过滤出失败任务，针对性重试
– **智能错误识别**：内置网络错误模式匹配，准确区分可重试的瞬态故障与不应重试的逻辑错误
## 显著优点
1. **高自动化**：无需人工干预，心跳触发即可自动检测并恢复
2. **精准过滤**：严格区分网络错误（ECONNREFUSED、ETIMEDOUT 等）与逻辑错误、认证失败，避免无效重试
3. **防循环设计**：检查 `lastRunAtMs` 时间戳，防止重复创建重试任务形成死循环
4. **透明可观测**：每次恢复尝试都会生成报告（”Recovered X jobs”），便于审计
5. **轻量集成**：仅需在心跳配置中添加几行 Markdown 指令即可启用
## 潜在缺点与局限性
– **依赖心跳频率**：恢复延迟取决于心跳触发间隔，非实时响应
– **误判风险**：某些边缘网络错误可能被误判为逻辑错误而跳过，或反之
– **幂等性要求**：被重试的任务本身需要具备幂等性，否则可能导致重复操作（如重复发送消息）
– **无指数退避**：文档未提及重试间隔退避策略，高频心跳可能导致过于密集的重试
– **单点状态依赖**：依赖 `cron list` 返回的状态准确性，若底层存储不一致可能导致误判
## 适合人群
– 运行大量网络依赖型定时任务的自动化代理用户
– 需要高可用消息推送、数据同步等场景的开发者和运维人员
– 使用 Telegram/Discord 等即时通讯 API 进行定时通知的用户（sendMessage 失败是典型场景）
– 网络环境不稳定（移动网络、间歇性连接）但仍需可靠任务执行的环境
## 常规风险
| 风险类型 | 说明 | 缓解措施 |
|———|——|———|
| 重复执行 | 非幂等任务被重复运行 | 确保任务逻辑幂等，或在任务内部实现去重 |
| 资源耗尽 | 心跳过于频繁导致密集重试 | 合理设置心跳间隔，监控重试频率 |
| 状态漂移 | 并发修改 `lastStatus` 导致误判 | 依赖底层 cron 工具的原子性保证 |
| 误恢复 | 非网络错误被误判为重试 | 定期审计恢复报告，调整错误模式匹配规则 |
## 总体评估
Cron Retry 是一项设计简洁、实用性强的容错技能，特别适合网络不稳定环境下的自动化运维。其”检测-分类-重试-报告”的闭环设计体现了良好的工程实践，但使用者需注意任务的幂等性设计和心跳频率调优。
会员专属
