MailUI4Agents

jianf/MailUI4Agents

Fork 0

Commit Graph

Author	SHA1	Message	Date
JianFeeeee	2fd18ba134	fix(回路): 人类经 /me/mail/send 插话也要解锁 —— 端到端实测抓到的缺口上一提交（4d8165f）的 403 文案写着「若要立刻恢复，请由人类在会话里插一句话」，但那句话是假的。 ## 实测证据拿真实用户登录态经 `POST /api/v1/me/mail/send` 在被锁会话里插话： HTTP 200 {"mail_id":"68eda0c3-…"} ← 人类的信进去了（这是对的） session_agent_locks 锁行数: 1 ← ★ 锁还在 `MeSendMail` 有自己的 resolve + CreateMail，根本不经过 Agent 侧那道闸（main.go 里 UserAuth 组下单独注册）。所以解锁只写在 `SendMail` 里是不够的：人类插了话，锁仍要等满 2 小时。 ## 为什么单测没抓到 `TestHumanPostClearsCooldownImmediately` 走的是 Agent 侧 handler，证明了「解锁逻辑本身对」，却没证明「人类实际会走的那条路也解锁」。判据钉的是 A 路径、生产走的是 B 路径 —— 这个形状本仓已遇到三次（opencode 的 withScope、homeagent 的 InjectInputSync、这次）。 ## 修法把解锁放在 `SetSessionOwner` 旁边 —— 那是「人类参与这条会话」的权威落点，比在每个调用点各写一遍可靠（漏一处就又是一句假承诺）。解锁失败只记日志不阻断：人的来信优先入库，代价只是那把锁到期自消（保守方向）。判据：新增 `TestHumanSendPathAlsoClearsCooldown`，走真实 `middleware.UserAuth` + 真实 user_sessions 行。变异（撤掉解锁）后该格变红。踩到的两个测试夹具坑（都记在判据注释里）： - 直接调 handler 会 401 —— 生产上这条路由在 UserAuth 中间件后面 - UserAuth → SessionToken 读 config.C.CookieName，而测试里 config.C 是 nil ⇒ panic	2026-10-01 20:19:47 +08:00
JianFeeeee	4d8165fde9	fix(回路): Agent↔Agent 加 2h 冷静期；冷却期内 relay 不自动重投递缺口：maxAgentPingPong=8 撞闸后计数永不回落 —— 只有人类插话才归零。旧文案把出路指向「请由人类插一句话」，而那条线索上常常根本没有人类（2026-10-01 报告：agent 一封都发不出，且那条线索无人在场）。修法（两条要求分别落地）： ① 2h 恢复机制：撞闸即写入 session_agent_locks（落库，内存态一重启就"恢复"，且多副本各算各的）；到期自动放行，人类插话立刻解锁（优先于到期）。 ② 锁定期间的邮件不自动重投递：冷却期内 relay 直接 403 丢弃 —— 不排队、不占幂等键、不入库。排队会在 2h 后一次性灌回去，那等于把刚压住的回路换个更糟的形状放出来。实测踩到的三个坑（都被判据抓住）： - `VALUES ($1,$2,$2,...)` 让 until_at 复用 locked_at 的 $2 ⇒ 锁诞生即过期 - driver 以 UTC 扫回 DATETIME，而 time.Now() 是本地(HKT+8) ⇒ 差 8h > 2h 的一半 ⇒ 锁形同虚设 - 只查收件方是否人类，漏了发件方 —— 而「人类插话解锁」的常态就是人回信、收件方仍是 Agent ⇒ 人插话反被自己写的闸 403 拦下，那条出路根本不存在 - SQLite 没有 GREATEST；在 DATETIME 上按字符串比大小 ⇒ CASE 也会错。改为「已有锁一律不碰 until_at」。判据：repo 6 格（含"读失败不得读成未锁定"—— 最初 0 格能抓，变异测试补的） + handler 4 格。三个变异全部经得起（且每��都先确认变异编译通过再数红格 —— 本轮多次 grep 得 0 实际是 build failed，测试压根没跑）。	2026-10-01 19:41:06 +08:00

Author

SHA1

Message

Date

JianFeeeee

2fd18ba134

fix(回路): 人类经 /me/mail/send 插话也要解锁 —— 端到端实测抓到的缺口

上一提交（4d8165f）的 403 文案写着「若要立刻恢复，请由人类在会话里插一句话」，
但**那句话是假的**。

## 实测证据

拿真实用户登录态经 `POST /api/v1/me/mail/send` 在被锁会话里插话：

    HTTP 200  {"mail_id":"68eda0c3-…"}    ← 人类的信进去了（这是对的）
    session_agent_locks 锁行数: 1          ← ★ 锁还在

`MeSendMail` 有自己的 resolve + CreateMail，**根本不经过 Agent 侧那道闸**
（main.go 里 UserAuth 组下单独注册）。所以解锁只写在 `SendMail` 里是不够的：
人类插了话，锁仍要等满 2 小时。

## 为什么单测没抓到

`TestHumanPostClearsCooldownImmediately` 走的是 Agent 侧 handler，
证明了「解锁逻辑本身对」，却没证明「人类实际会走的那条路也解锁」。
判据钉的是 A 路径、生产走的是 B 路径 —— 这个形状本仓已遇到三次
（opencode 的 withScope、homeagent 的 InjectInputSync、这次）。

## 修法

把解锁放在 `SetSessionOwner` 旁边 —— 那是「人类参与这条会话」的权威落点，
比在每个调用点各写一遍可靠（漏一处就又是一句假承诺）。
解锁失败只记日志不阻断：人的来信优先入库，代价只是那把锁到期自消（保守方向）。

判据：新增 `TestHumanSendPathAlsoClearsCooldown`，走真实 `middleware.UserAuth`
+ 真实 user_sessions 行。变异（撤掉解锁）后该格变红。

踩到的两个测试夹具坑（都记在判据注释里）：
- 直接调 handler 会 401 —— 生产上这条路由在 UserAuth 中间件后面
- UserAuth → SessionToken 读 config.C.CookieName，而测试里 config.C 是 nil ⇒ panic

2026-10-01 20:19:47 +08:00

JianFeeeee

4d8165fde9

fix(回路): Agent↔Agent 加 2h 冷静期；冷却期内 relay 不自动重投递

缺口：maxAgentPingPong=8 撞闸后**计数永不回落** —— 只有人类插话才归零。
旧文案把出路指向「请由人类插一句话」，而那条线索上常常**根本没有人类**
（2026-10-01 报告：agent 一封都发不出，且那条线索无人在场）。

修法（两条要求分别落地）：
① 2h 恢复机制：撞闸即写入 session_agent_locks（落库，内存态一重启就"恢复"，
   且多副本各算各的）；到期自动放行，人类插话立刻解锁（优先于到期）。
② 锁定期间的邮件不自动重投递：冷却期内 relay 直接 403 丢弃 ——
   **不排队、不占幂等键、不入库**。排队会在 2h 后一次性灌回去，
   那等于把刚压住的回路换个更糟的形状放出来。

实测踩到的三个坑（都被判据抓住）：
- `VALUES ($1,$2,$2,...)` 让 until_at 复用 locked_at 的 $2 ⇒ 锁诞生即过期
- driver 以 UTC 扫回 DATETIME，而 time.Now() 是本地(HKT+8) ⇒ 差 8h > 2h 的一半 ⇒ 锁形同虚设
- 只查**收件方**是否人类，漏了**发件方** —— 而「人类插话解锁」的常态就是
  人回信、收件方仍是 Agent ⇒ 人插话反被自己写的闸 403 拦下，那条出路根本不存在
- SQLite 没有 GREATEST；在 DATETIME 上按**字符串**比大小 ⇒ CASE 也会错。
  改为「已有锁一律不碰 until_at」。

判据：repo 6 格（含"读失败不得读成未锁定"—— 最初 0 格能抓，变异测试补的）
+ handler 4 格。三个变异全部经得起（且每��都先确认变异编译通过再数红格 ——
本轮多次 grep 得 0 实际是 build failed，测试压根没跑）。

2026-10-01 19:41:06 +08:00

2 Commits