JianFeeeee
2922fb711f
起因：用户邮箱里「[dsh] 桥服务异常终止」反复出现。查下来有两层。
**第一层：崩溃本身（已修，是历史）**
dsh 在 2026-09-12 11:40 起崩溃循环，根因是当时那次插件快照切换后
`/root/.dsh/profiles/web/node_modules/dsh-mail-bridge/cordis.patch.yml` 不存在
（`failed to read overlay … ENOENT`）→ 起不来 → systemd 反复重启。
现在快照里该文件在、dsh `NRestarts=0`、今天 0 次失败。
**第二层：通知管线本身坏了（本次修）**
1. ★ **死信目录**：`zcode.service`（应用单元）既没有 `AGENTMAIL_AGENT_NAME` 也没有
密钥，报告就落进 `unknown-agent/` —— 而 flush **只读自己那个 Agent 的目录**，
于是 25 份 zcode 崩溃告警永久投不出去。修法是两件事：
· `resolveIdentity()`：身份按「单元 env → 单元名推导 → /etc/agentmail/<agent>.env」
解析；`zcode.service`→zcode、`pi-mail-bridge.service`→pi……
· 支持 `AGENTMAIL_AGENT_SECRET`：zcode 只配了 secret 没有 key，而脚本原先只认
Bearer key ⇒ 就算目录对了也发不出去（网关的 AgentAuth 两种都认）。
2. ★ **隔夜补投**：补投原先只在**同一个单元**的下次 `ExecStartPost` 跑，于是
网关不可达时攒下的报告要等到那个服务自己重启才补投 —— 实测 4 封 Sep-12 的
告警在 Sep-13 10:35 才到。现在新增 `agentmail-failure-flush.timer`（每 10 分钟
`--flush-all`），它遍历所有 Agent 目录、按目录名逐个解析身份后补投。
过时报告还会在主题与正文上标 **「补投：这是 N 分钟前的故障报告，不代表现在仍在
故障」**（原先正文里只有昨天的时间戳，读起来像刚崩）。
3. **补投失败只报数不报因**：`catch { failed++ }` → 日志只有 `spool: sent=0 failed=4`，
没人知道卡在哪。现在每条失败都带回原因（HTTP 状态码/网关不可达/身份未配置）。
4. 顺带两处准确性问题：
· 主题写**单元名**而不是笼统的「桥服务」—— 25 封标题写着"桥服务异常终止"，
实际崩的是 zcode **应用**单元，照标题去查桥方向就错了。
· `created_at_ms` 是我们的元数据，但 `/mail/send` 是**严格解码**的（实测 400
不认识的字段）→ 发送前剥离，线格式保持干净。
判据：新增 `deploy/service-failure-notify.test.mjs`（12 条，含假网关做真实投递、
严格解码断言、补投标记的正反两向）。端到端验证：模拟"没有身份的 zcode.service
崩溃"——修复前落 `unknown-agent/` 永久死信；现在**真的投出去了**，且
`from_name=zcode`、主题 `[zcode] zcode.service 异常终止 #…`。
积压清理：27 份（dsh 2 + unknown-agent 25）全部来自 09-12 那两轮崩溃、事件已在
邮箱与 journal 里出现过，按**不再补投**处理（避免把隔夜告警灌进邮箱），
原始文件留档 /root/gotmp/failure-spool-backlog-20260913.tar.gz（600），
spool 目录留 README.md 说明。
11 lines
158 B
SYSTEMD
11 lines
158 B
SYSTEMD
[Unit]
|
|
Description=每 10 分钟补投 AgentMail 故障通知
|
|
|
|
[Timer]
|
|
OnBootSec=2min
|
|
OnUnitActiveSec=10min
|
|
Persistent=true
|
|
|
|
[Install]
|
|
WantedBy=timers.target
|