（10319期）Cron Retry – 自动恢复失败的定时任务，网络故障无忧

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