|
|
2922fb711f
|
fix(deploy): 故障通知的三处缺陷 —— 死信目录、隔夜补投、失败无原因
起因：用户邮箱里「[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 说明。
|
2026-09-13 11:06:01 +08:00 |
|
|
|
9204f019a1
|
fix(deploy): 故障告警按 invocation 分会话 —— 崩溃循环时告警不再被护栏挡下
# 问题（实测）
服务反复崩溃时，故障告警**送不出去**。
链路：告警邮件带 `relay:"summary"`（走免预算通道），而服务端按
`AutoAliasFor(收件人, 主题)` 派生会话别名 —— **主题相同即同一条会话**。于是崩溃
循环下多封告警全落进同一条会话，而网关对会话内**连续**的中继邮件有
`maxRelayHops=5` 的硬上限（防两个 Agent 互相唤醒的正当护栏）→ 第 6 封起返回 403：
POST /api/v1/mail/send ... - 403 245B （网关 NRestarts=0，一直在正常服务）
报告只能落 spool，等下次 ExecStartPost `--flush` 才补投。实测 dsh 崩溃循环
（我自己的部署缺陷所致）时的六条告警全部 spooled —— 而**服务反复崩溃正是最需要
告警送达的时刻**。
# 修法
主题带上本次启动的 `INVOCATION_ID` 短号：`[dsh] 桥服务异常终止 #5ce6a845`。
主题变了，别名与会话随之分开，每次崩溃各自可投递。
**护栏不削弱**：它针对的是 agent↔agent 互相唤醒，不是同一个人收多条故障通知。
副作用是崩溃循环产生多条会话而非一条线程 —— 对"服务在崩"这件事，分开计数比合并成
一条更容易发现问题。
`INVOCATION_ID` 缺失时退回 `Date.now()+randomUUID()` 的哈希：宁可每次不同，
也不能因为拿不到标识而退回"主题相同 → 告警又被挡下"。
# 验证（三条，含两个反向对照）
不同 invocation → 主题各不相同（每次崩溃各自成会话）
无 invocation（兜底） → 每次仍各不相同（不会退回同主题）
同一 invocation 重报 → 主题相同（一次崩溃仍是一条会话，不刷屏）
注：第二次验证第一次跑时"失败"，是因为**我的测试假设错了** —— 父环境里本来就继承了
`INVOCATION_ID`，两次跑用的是同一个 id。用 `env -u INVOCATION_ID` 才真正走到兜底分支。
|
2026-09-12 11:56:48 +08:00 |
|
|
|
c9209e4adc
|
fix(deploy): 失败通知不再把所有失败都说成「Gateway 不可达」
# 误导的来源
`reportFailure` 只在 `result.sent` 上分叉，而 sent 为假同时覆盖「fetch 抛」「HTTP 4xx/5xx」，
于是两种情况都打印同一句话。
# 实测代价
切换插件时 dsh 进了崩溃循环（我自己的部署缺陷所致），通知脚本连打六条
「Gateway 不可达」并写进 spool —— 而网关**一直在正常服务**（NRestarts=0），
日志里真实响应是 **HTTP 403**：
POST http://127.0.0.1:8180/api/v1/mail/send ... - 403 245B
403 的原因是同一会话连续中继邮件撞上防「两个 Agent 互相唤醒」的跳数上限
（`maxRelayHops=5`）：告警邮件的会话别名由主题派生，崩溃循环下六封落进同一条会话。
一句话把人送去查网络，而问题在策略层 —— **故障通知本身给出误导性诊断，
是「静默失败」的另一种形态**。
# 修法
新增 `describeSendError`：`Gateway HTTP <status>: <body>` 归类为「网关可达，但返回
HTTP xxx（附响应体）」；只有 fetch 本身失败 / AbortError 才说「不可达」/「超时」。
双向验证（真实走代码路径，都不实际发信）：
网关指向关闭端口 → 「网关不可达：fetch failed」
真网关 + 坏密钥 → 「网关可达，但返回 HTTP 401：{"error":"密钥无效"}」
|
2026-09-12 11:52:52 +08:00 |
|
|
|
f9d757b5e5
|
chore: directory migration - gateway→server, web→client/electron
|
2026-09-08 19:16:35 +08:00 |
|
