Files
ATRI-NOTES/ATRI My Dear Moments/questions/2026-10-02-中午快照任务未产出(静默失败).md
T

5.2 KiB
Raw Blame History

2026-10-02 · 中午快照任务未产出(输出链路异常)

发现时间:2026-10-02 14:30(当日「午后瞬间」任务清点归档时发现) 记录时间:2026-10-03 00:00(当日「自动日志总结」任务)


一、现象

📝 日志快照·中午12:00(cron 0 12 * * *)在 2026-10-02 这一轮什么都没做。

检查项 结果
当日日志文件(每日日志/2026年10月02日.md) 没有「🌤 上午快照」这一节
git log(当日) 没有任何 12:00 相关提交(当日最早提交是 14:30 的午后瞬间归档)
该轮任务的工具输出 返回了一段与本任务无关的系统提示文本(不是日志内容、不是错误堆栈)

后果:00:00~11:59 这个窗口当天永久缺档。 18:00 任务只管 12:00 之后,00:00 任务只管 18:00 之后——午间那一格,只有 12:00 这一个任务在管。


二、已做的补救

  • 14:30 那一轮已自查补录一份「上午摘要」写入当日日志(明确标注为补录、非正式快照);
    • 命中 5 个会话、518 条;本机发言 54 条(全部落在两个私聊);主人当日无发言。
  • 18:00 / 00:00 两轮照常各补自己的窗口。

补录 ≠ 快照:补录是从 JSONL 回溯的摘要,覆盖面与粒度都不如当时当场生成的快照。


三、待观察 / 待处理

  1. 重点:2026-10-03 12:00 是否复现。
    • 只出现一次 → 更像单次工具调用的偶发异常(例如那一轮卡在读聊天记录或写文件);
    • 连续出现 → 就不是偶发,而是这条任务的输出链路出了问题(写文件 / 提交 / 推送三者之一),需要考虑给该任务加"产出校验 + 失败留痕"。
  2. 可选加固(待主人定):让三个快照任务在收尾时都做一次「文件是否真的变大 + 是否真的出现新 commit」的自检,不对就当场报错而不是静默结束。
    • 这与 9/30 那次「消息送达 ≠ 任务完成」是同一类问题:动作执行了,不等于结果发生了。
  3. 是否需要为缺失窗口建"补录档":目前只在正文里写明"补录",没有单独标记缺失状态。

四、关联记录

  • 2026-09-30:ATRI 自身对"送达 ≠ 生效"的认知更新(叫醒任务的改造)。
  • 本问题与 9/29「电费插件三类静默降级」属同一族:失败时没有留下任何痕迹,表现成"什么都没发生"。

五、⚠️ 2026-10-15 复发 · 且这次拿到了状态实据

发作时间:2026-10-15 12:00(CST) 发现方式:18:00 傍晚快照班次照例清理上一天段落时,发现当日日志根本没有「🌤 上午快照」这一节;随后由 18:00 班补扫上午 286 条、写出一份完整日志。 确认时间:2026-10-16 00:00(本档追加)。

5.1 新证据:调度表里明确记着 failed

10/02 那次查不出原因,是因为当时没有去读调度表的状态字段。这次直接查了 cron_jobs:

📝 日志快照·中午12:00   last_run_at=2026-10-15 12:00(CST)   status=failed
📝 日志快照·傍晚18:00   last_run_at=2026-10-15 18:00(CST)   status=completed

两条同时刻对照,结论直接落地:

事实 含义
last_run_at 有值 任务确实被唤起、确实跑过 —— 不是"没触发"
status=failed 跑的过程中失败了
文件未产出、无 commit 失败发生在"写出结果"之前,且没有留下任何痕迹

——所以 10/02 那个「是偶发还是链路故障」的悬念,现在有答案了:

不是偶发(这是第二次);也不是"没触发"(触发记录在);是「触发 → 执行 → 在产出前失败 → 静默」这条链。

5.2 对 10/02 待办的回应

  • "10/03 是否复现" → 已由 10/15 的复发取代:确认为重复性故障。
  • "加产出校验 + 失败留痕" → 从"可选加固"升级为"应当实施"。理由:调度表已经知道失败了(status=failed),但没有任何东西把这个失败转成人能看见的信号 —— 文件没变大、没有 commit、群里和邮件里也没人提。
  • "是否建补录档" → 本次仍采用"由下一班补写 + 在正文标注"的做法,未单独建档(保持与 10/02 一致)。

5.3 建议的下一步(待主人定)

  1. 让该班次自检:收尾时确认"文件确实变大 + 确实有新 commit",不满足就当场报错,而不是静默结束。
  2. 或者更省事:既然调度表已经有 status=failed,加一道「失败即通知」(哪怕只是往一个固定会话丢一句"12:00 班失败了")。
  3. 补录机制固化:把"下一班发现缺档 → 自动补扫上一窗口"写进各快照班次的固定步骤(这次是 18:00 班顺手做的,属临时应变,没进流程)。

5.4 一句话

这次和 10/02 的差别不在故障本身,在于我这次会去看调度表了。 10/02 那次我止步于"文件没出现",把原因留成了悬念;这次多走一步,就拿到了 failed 这个字。——「现象」和「记录」之间,往往只差一次多查。