诊断定时任务是“未触发”还是“执行失败”

帮助你用日志和运行记录证明 cron/定时任务的真实故障位置，避免把“调度正常但执行失败”误判为“任务根本没跑”。

When to use this skill

• 当你需要判断“定时任务没执行”到底是调度器没触发，还是任务已被拉起但在执行阶段失败。
• 当你要为事故结论提供证据，尤其是需要证明“不是模型本身导致没跑”，而是 workspace、授权、会话、token 或超时问题。
• 当你已经修复了授权、配置或网关，想验证系统是否真正恢复，而不是只看服务进程是否在线。
• 当用户描述为“cron 挂了”“自动任务最近都失效”“重启后想确认恢复”“日志里有 deactivated_workspace / oauth token invalid / timeout”等情况。

Steps

1. 先把问题拆成两条证据链：调度是否发生、执行是否成功。
   先明确不要直接接受“任务没执行”的表述，而要分别查：

   • 网关/调度日志里是否有 cron 触发痕迹
   • 任务注册信息、最近运行时间、运行状态、错误码
     这样做的原因是：很多故障并不是“没调度”，而是“调度正常但执行失败”，两者结论完全不同。

2. 列出当前系统中的定时任务，并核对最近一次运行记录。
   重点抓每个任务的：

   • 任务名
   • 最近运行时间
   • 状态：ok / error
   • 错误详情
     本次排查中，确认系统里有 9 个 cron 任务，且多个任务都带有明确的最近运行时间与错误状态，例如：
   • obsidian-discord-guild-daily-review-final
   • juejin-daily-checkin-lottery
   • seedpool-daily-auto-publish
   • dispatch-thread-rename-backstop
     这样做的原因是：只要“最近运行时间”存在，就能证明任务并非完全没被调度。

3. 用“最近运行时间 + error 状态”证明任务其实被触发过。
   本次实际查到的关键证据是：

   • obsidian-discord-guild-daily-review-final
     • 最近运行：2026-03-12 05:00
     • 状态：error
     • 错误：{"detail":{"code":"deactivated_workspace"}}
   • juejin-daily-checkin-lottery
     • 最近运行：2026-03-12 09:10
     • 状态：error
     • 错误：{"detail":{"code":"deactivated_workspace"}}
   • seedpool-daily-auto-publish
     • 最近运行：2026-03-12 09:30
     • 状态：error
     • 错误：{"detail":{"code":"deactivated_workspace"}}
   • dispatch-thread-rename-backstop
     • 最近运行：2026-03-12 23:30 左右
     • 状态：error
     • 错误：{"detail":{"code":"deactivated_workspace"}}
     • 且连续错误 9 次
       这样做的原因是：这组证据足以支撑“调度器在跑，任务也被拉起了，但执行时失败”。

4. 继续向前翻运行历史，判断是长期配置问题还是近期退化。
   本次实际核对到：

   • Discord 日整理：3/05、3/06、3/07、3/08、3/09、3/10 都有 ok
   • 掘金签到：3/05 到 3/11 多日都有 ok
   • Seedpool 日报：3/09、3/10、3/11 都有 ok
     这样做的原因是：如果同一批任务前几天长期正常，就更像“最近运行环境或授权状态变了”，而不是 cron 从一开始就没配好。

5. 汇总错误类型，不要只盯一个模型或一次失败。
   本次实际观察到三类错误：

   • deactivated_workspace
   • Encountered invalidated oauth token for user, failing request
   • Error: cron: job execution timed out
     这样做的原因是：如果错误集中在 workspace、OAuth、超时层，而不是输出内容异常，就应把排查重点放在运行环境、鉴权和会话，而不是先怪模型能力。

6. 核对历史 runs 用过的模型/供应商，避免把“碰巧用了某模型”误当根因。
   本次实际看到历史上跑过多个模型/供应商：

   • openai-codex / gpt-5.3-codex
   • openai-codex / gpt-5.4
   • aigocode / claude-sonnet-4-6
   • aigocode / claude-opus-4-6
   • minimax-portal / MiniMax-M2.5
     这样做的原因是：如果多个供应商和模型都跑过，而最近主错误仍然统一是 deactivated_workspace，那更像共享执行环境失活，而不是某个模型“把任务搞没了”。

7. 先给出保守结论：能证明异常存在，但不能越过证据下结论。
   在未拿到更多上下文前，本次形成的正确表述是：

   定时任务并非未触发，而是在最近几次调度中于执行阶段集中失败；主要错误为 deactivated_workspace，另有 OAuth token 失效与超时情况。现有日志不足以证明是模型能力本身导致，更像是 workspace / 会话 / 鉴权层异常影响了任务执行。
   这样做的原因是：事故表述需要和证据严格对齐，先区分“可证实”和“待确认”。