reader/plans/issues/2026-04-06-reader-digest-sigterm.md

reader 日报链路在 OpenClaw/Feishu 外层执行中被 SIGTERM 截断

背景

2026-04-06 在 OpenClaw 中执行 reader 日报流程时，出现多次“前半段有产物、最终产物缺失”的现象。

典型表现：

• 能生成 raw/freshrss.raw.json
• 能部分生成 extracted/item-xx.extracted.json
• 但经常拿不到：
  • run-report.json
  • candidates/openclaw-delivery-payload.json
  • candidates/digest-brief.json
• 外层日志多次出现 Exec failed (..., signal SIGTERM)

已确认结论

1. RSS 抓取与排序正常

已确认：

• FreshRSS API 正常
• 原始 raw 数据能拉到
• 默认排序正常（默认相当于 r=d，新到旧）

因此问题不在：

• RSS 接口
• 鉴权
• 排序规则

2. reader 前半段模块正常

已确认：

• 单篇 summary 能成功
• 单篇 filter + candidate 构建能成功

因此问题不在：

• summary 模块整体损坏
• candidate 构建整体损坏

3. 真正问题在长链路执行方式

更合理的判断是：

整条 reader 日报 pipeline 是长串行任务，在 OpenClaw / Feishu 当前这条外层执行链路里，容易被外层执行环境提前 SIGTERM。

也就是说：

• 不是 reader 总是自己抛 Python 异常退出
• 更多是脚本尚未跑完，外层执行会话先被终止

关键认知

当天很多排障与补跑步骤，实际不是通过稳定常驻的 MCP 服务在跑，而是直接执行 reader 仓库里的 Python 脚本：

• python scripts/run_freshrss_pipeline.py
• python scripts/run_article_summaries.py

因此更准确地说：

当前 reader 正式日报运行入口偏 CLI/脚本模式，而不是稳定 MCP 服务调用模式。

这也是为什么长任务更容易受外层 exec 生命周期影响。

为什么前几次没问题

可能原因：

1. 之前任务更短、内容更轻，刚好能在外层执行环境截断前跑完
2. 之前不是链路天然稳，而是还没撞上边界条件
3. 当前正式链路缺少稳健的断点恢复能力，因此一旦遇到较重任务，就暴露出问题

当天动作记录

做过的排查

• 确认 FreshRSS 默认排序
• 确认 raw 文件能生成
• 确认 extracted 文件能部分生成
• 单独验证单篇 summary 成功
• 单独验证单篇 filter / candidate 成功

做过的临时修复

当天曾尝试加入：

• --resume
• 中间产物复用
• 断点恢复思路

目的是降低 SIGTERM 后的损失。

当前状态

这些临时代码修改已全部回滚，reader 工作区已恢复干净。

当天结果

虽然正式链路异常，但通过手工恢复推进，最终仍补齐了：

• candidates/openclaw-delivery-payload.json
• candidates/digest-brief.json
• run-report.json

当天最终保留文章：

• 1
• 3

后续建议

短期

• CLI 仅保留为 debug / fallback
• 不再把正式生产日报流主要建立在长脚本入口上

中期

• 将 reader 作为正式 MCP 服务
• OpenClaw 正式通过 MCP tool 调用：
  • run_freshrss_openclaw_pipeline
  • generate_article_summaries

长期

让 reader 的正式能力具备：

• run_id
• status 查询
• resume
• 中间产物复用
• 分阶段补跑