fix(inbox): 收件箱按**工作区**收窄（三维地址的 path 位此前从未被使用）
用户 12 天前就提过（`552fbc7` 只修了 session_id 那一维），这轮才真修。 用户原话：「难道让一个不在项目工作区的 agentsession 去修工程吗？」 # 缺陷（生产实测，2026-09-26） 在 `mc` 工作区干活的 pi 读收件箱拿到 **200 封，其中 191 封属于 `/home/program/agentmail`** —— 它照着那些信里的断言去改 agentmail 的代码， 把手上的 mc 活丢在一边。用户当场问它「你怎么干着干着修 agentmail 去了？」 （这条对话就在 mc 会话的 jsonl 里） 根因：`ListInboxScoped` 的 WHERE 只有 `m.to_name = $1`（+ 可选 session_id）， **没有任何 workspace 条件**。三维地址 `name@path.session` 的 path 位 在收件箱侧从未生效 —— 那不是"另一种语义"，是没兑现契约。 # 三条守卫全部只覆盖自动转发，防不住这个 | 守卫 | 只覆盖 | 为何无效 | | --- | --- | --- | | 会话预算 | `relay != ""` 才扣 | 这批信 relay=0（模型主动发）⇒ 不扣 | | maxRelayHops=5 | 同上，只数 relay | 同上 ⇒ 不进那个分支 | | 插件自动转发守卫 | 插件代劳时 | 日志明说"本轮不自动转发" ⇒ 模型自己发的不受管 | # 服务端 · `ListInboxScoped` / `CountUnreadScoped` / `MarkAllInboxReadForSession` 三处统一加 `s.workspace = $N`（用会话的 workspace，不用 mails.to_workspace： 后者是信封字段、可能是抄送或历史遗留；"线索属于哪个工作区"是会话属性）。 ★ 三处必须是**同一个谓词** —— 列表看不到的信却被"全部标掉"标掉就是静默丢信 （session_scope_test.go 记过这个形状）。 · **workspace 在 Agent 侧必需，缺了 400**（用户裁定：「不带 workspace 是错误 发件格式，直接退回！」）。旧语义（不带=全部）正是缺陷本身，不留兼容回退。 · 人类侧**不过滤**（一个人跨工作区，WebUI 按 session_workspace 分组显示）—— 所以"必需"这条约束放在 Handler 而不是 repo 层：它是接口契约，不是数据层不变量。 · 新增 `UnreadWorkspaces`：心跳是**进程级**（一个桥服务所有工作区），没有 "我的工作区"可言；但只有总数桥不知道去哪个工作区补投 ⇒ 心跳回 `pending_workspaces` 清单，桥逐个消费。 · 决策载荷补 `workspace`（服务端知道 session→workspace，插件重启后推不出来）。 · `TouchAgentLastSeen` 从 HeartbeatAgent 拆出：middleware 在每个认证请求上都调它， 而那时工作区还没解析（请求体没读），原来在白算一次 CountUnread。 # 三个插件（pi / opencode / dsh） · 读类工具带 `workspace`；补投从"读一次全局收件箱"改为**逐工作区**读。 · pi：worker 信封的 `to_workspace` 经闭包递进工具（不是会话文件 header 的 cwd —— 后者是"会话上次落在哪"，前者是"这封信寄到哪个工作区"）。 · opencode/dsh：插件常驻、信封在 deliverMail 那刻就消费掉了 ⇒ 新增 `sessionWorkspace` 映射（键与既有 reverseMap 同一把）。 · 修一处真 bug：`UnreadWorkspaces` 原先会返回相对路径工作区（历史库里有 `workspace='root'`），桥侧实测撞 400（`补投工作区 root 失败`）⇒ 只报可寻址的。 # 实测凭据 · 改前：`pi` 的收件箱 200 封混 3 个工作区（agentmail 191 / TrueAgent 7 / huawei 2） · 改后：agentmail=100（total 228）、mc=16、TrueAgent=7 —— 各工作区独立 · 不带 workspace ⇒ **HTTP 400**，话术给出可执行步骤 · 桥日志：`rw=/home/newqqagent/plugindev/editdoc-upgrade` —— 终于是别的工作区了 （改前 78 次 worker 启动**全部**是 `/home/program/agentmail`） # 判据 · `server/internal/repo/workspace_scope_test.go`（3 条）： 两向收窄 + **反向对照**（不带时两条都看得到 ⇒ 证明是收窄不是清空）+ 未读数同口径 + 相对路径必须报错 · `plugins/pi-mail-bridge/test/inbox-workspace-scope.test.mjs`（4 条）：接线 + 取信封而非 cwd + 补投逐工作区 + 判据自检 · dsh 那条 `取不到会话时退回整体收件箱` **改了**：它钉的"退回整体"正是缺陷， 现在钉"两维各自缺席时各自不带、服务端 400 让错误可见" · 变异验证：服务端 2 处 + 插件 3 处，全部判红后恢复回绿 全量：server `go test ./...` 绿；三插件 513+340+403 全绿。
This commit is contained in:
@ -173,6 +173,20 @@ class GatewayClient {
|
||||
|
||||
const sessionMap = new BoundedMap<string, { dshSessionId: string; directory: string }>(MAX_TRACKED_SESSIONS);
|
||||
const reverseMap = new BoundedMap<string, string>(MAX_TRACKED_SESSIONS);
|
||||
|
||||
/*
|
||||
★ 2026-09-26：DSH 会话 id -> **工作区**。
|
||||
|
||||
收件箱接口现在要求 `workspace`（缺了 400），而 `read_inbox` 的 URL 是从
|
||||
`exec.agent` 现场拼的 —— 那里只有 DSH 的会话 id，推不出工作区。
|
||||
信封（`data.to_workspace`）在 `deliverMail` 那一刻就消费掉了，
|
||||
到 `read_inbox` 时已不在作用域里 ⇒ 在这里留一份映射。
|
||||
|
||||
用户报的缺陷（这一维此前完全没做）：在 `mc` 工作区干活的会话读收件箱拿到
|
||||
agentmail 的信，照着去改 agentmail 的代码。三维地址 `name@path.session`
|
||||
的 **path 位本来就该参与寻址**。
|
||||
*/
|
||||
const sessionWorkspace = new BoundedMap<string, string>(MAX_TRACKED_SESSIONS);
|
||||
const mailDrivenSessions = new BoundedSet<string>(MAX_TRACKED_SESSIONS);
|
||||
// 回信上下文。fromHuman / inReplyTo 是服务端给的两个信号：
|
||||
// 前者决定要不要自动转发（Agent 间不转，见 lib/relay-policy.js），
|
||||
@ -475,27 +489,43 @@ export function apply(ctx: any, config: PluginConfig): void {
|
||||
* SSE 只推连上之后的事件，插件重启前发来的邮件不会再推一次。
|
||||
* 不补的话那封邮件永远躺在收件箱里，而发件人以为 Agent 收到了。
|
||||
*/
|
||||
async function catchUp(pending: unknown): Promise<void> {
|
||||
async function catchUp(pending: unknown, workspaces?: unknown): Promise<void> {
|
||||
if (!pending) return;
|
||||
try {
|
||||
const box = await client.get('/mail/inbox?status=unread&limit=20');
|
||||
const tasks = selectCatchup(box?.mails ?? box, deliveredMails);
|
||||
if (tasks.length === 0) return;
|
||||
console.error(`[dsh-mail-bridge] 补投 ${tasks.length} 封离线期间的邮件（共 ${pending} 封未读）`);
|
||||
// 串行：每封都要起一轮模型，并发放出去等于对上游打 N 个并发请求
|
||||
for (const ev of tasks) {
|
||||
// 逐封再查一次：拉收件箱和逐封投递之间 SSE 可能已经投过其中某封
|
||||
if (deliveredMails.has(ev.mail_id)) continue;
|
||||
deliveredMails.add(ev.mail_id);
|
||||
try {
|
||||
await deliverMail(ev, 'mail');
|
||||
} catch (e: any) {
|
||||
console.error(`[dsh-mail-bridge] 补投 ${ev.mail_id} 失败: ${e?.message || e}`);
|
||||
}
|
||||
}
|
||||
} catch (e: any) {
|
||||
console.error(`[dsh-mail-bridge] 补投失败: ${e?.message || e}`);
|
||||
/*
|
||||
★ 逐工作区补投，不再读一次全局收件箱。
|
||||
旧写法不带收窄 ⇒ 会把**所有工作区**的漏投一起重放（在 mc 干活却被补投
|
||||
agentmail 的信）。清单来自心跳的 `pending_workspaces`：心跳是进程级、
|
||||
没有"我的工作区"可言，所以由它给清单，这里逐个消费。
|
||||
*/
|
||||
const list = Array.isArray(workspaces) ? (workspaces as string[]) : [];
|
||||
if (list.length === 0) {
|
||||
console.error(`[dsh-mail-bridge] 补投跳过：pending_mails=${pending} 但服务端未给出 pending_workspaces（旧版服务端？）`);
|
||||
return;
|
||||
}
|
||||
let delivered = 0;
|
||||
for (const ws of list) {
|
||||
try {
|
||||
const box = await client.get(`/mail/inbox?status=unread&limit=20&workspace=${encodeURIComponent(ws)}`);
|
||||
const tasks = selectCatchup(box?.mails ?? box, deliveredMails);
|
||||
if (tasks.length === 0) continue;
|
||||
// 串行：每封都要起一轮模型，并发放出去等于对上游打 N 个并发请求
|
||||
for (const ev of tasks) {
|
||||
// 逐封再查一次：拉收件箱和逐封投递之间 SSE 可能已经投过其中某封
|
||||
if (deliveredMails.has(ev.mail_id)) continue;
|
||||
deliveredMails.add(ev.mail_id);
|
||||
try {
|
||||
await deliverMail(ev, 'mail');
|
||||
delivered += 1;
|
||||
} catch (e: any) {
|
||||
console.error(`[dsh-mail-bridge] 补投 ${ev.mail_id} 失败: ${e?.message || e}`);
|
||||
}
|
||||
}
|
||||
} catch (e: any) {
|
||||
// 单个工作区失败不影响其余（与"心跳失败不报错"同一原则）
|
||||
console.error(`[dsh-mail-bridge] 补投工作区 ${ws} 失败（不影响其余）: ${e?.message || e}`);
|
||||
}
|
||||
}
|
||||
if (delivered) console.error(`[dsh-mail-bridge] 补投 ${delivered} 封离线期间的邮件（共 ${pending} 封未读，跨 ${list.length} 个工作区）`);
|
||||
}
|
||||
|
||||
async function beat(): Promise<void> {
|
||||
@ -523,7 +553,7 @@ export function apply(ctx: any, config: PluginConfig): void {
|
||||
// 每轮心跳都补的话会把「模型正在处理中、尚未标已读」的邮件重复投递。
|
||||
if (!caughtUp) {
|
||||
caughtUp = true;
|
||||
await catchUp(res?.pending_mails);
|
||||
await catchUp(res?.pending_mails, res?.pending_workspaces);
|
||||
}
|
||||
} catch {
|
||||
// 心跳失败不报错：网络抖动很常见，下一轮会补上。
|
||||
@ -871,6 +901,14 @@ export function apply(ctx: any, config: PluginConfig): void {
|
||||
* 取不到返回空串（= 退回整个 Agent 的收件箱）。宁可退回旧行为，也不猜 ——
|
||||
* 猜错会把别人会话的未读标掉，那是静默丢信。
|
||||
*/
|
||||
/** 这次调用所属会话的工作区（与 mailSessionOf 同一把键）。拿不到返回空串 —— 那时
|
||||
* 收件箱请求会 400，是刻意的：错误可见，好过静默跨工作区拿到别处的信。 */
|
||||
function workspaceOf(exec: any): string {
|
||||
const dshSessionId = exec?.agent?.id ?? exec?.agent ?? '';
|
||||
if (!dshSessionId) return '';
|
||||
return sessionWorkspace.get(String(dshSessionId)) ?? '';
|
||||
}
|
||||
|
||||
function mailSessionOf(exec: any): string {
|
||||
const dshSessionId = String(exec?.agent?.id ?? '');
|
||||
if (!dshSessionId) return '';
|
||||
@ -919,6 +957,8 @@ export function apply(ctx: any, config: PluginConfig): void {
|
||||
const cwd = String(agent?.session?.header?.cwd ?? '');
|
||||
sessionMap.set(mailSessionID, { dshSessionId: id, directory: cwd });
|
||||
reverseMap.set(id, mailSessionID);
|
||||
/* 会话自己的 cwd 就是它的工作区 —— read_inbox 的收窄要用它 */
|
||||
if (cwd) sessionWorkspace.set(id, cwd);
|
||||
mailDrivenSessions.add(id);
|
||||
console.error(`[dsh-mail-bridge] 由确定性 id 恢复会话映射 ${mailSessionID} -> ${id}`);
|
||||
}
|
||||
@ -963,6 +1003,8 @@ export function apply(ctx: any, config: PluginConfig): void {
|
||||
if (!mailSessionID) return;
|
||||
sessionMap.set(mailSessionID, { dshSessionId, directory: cwd });
|
||||
reverseMap.set(dshSessionId, mailSessionID);
|
||||
/* 同上：cwd 即工作区 */
|
||||
if (cwd) sessionWorkspace.set(dshSessionId, cwd);
|
||||
mailDrivenSessions.add(dshSessionId);
|
||||
mailContexts.set(mailSessionID, {
|
||||
replyTo: data.from_name || '',
|
||||
@ -1341,7 +1383,15 @@ export function apply(ctx: any, config: PluginConfig): void {
|
||||
async execute(args: any, exec?: any): Promise<string> {
|
||||
const status = args.status || DEFAULT_INBOX_STATUS;
|
||||
const mailSessionID = mailSessionOf(exec);
|
||||
const scope = mailSessionID ? `&session_id=${encodeURIComponent(mailSessionID)}` : '';
|
||||
/*
|
||||
★ 两维收窄都要带：
|
||||
· session_id —— 只列**这条线索**的信（防"A 会话标掉 B 会话的未读"）
|
||||
· workspace —— 只列**这个工作区**的信（防"在 mc 干活却读到 agentmail 的信"）
|
||||
服务端对缺 workspace 直接 400 —— 刻意如此（旧语义正是那个缺陷本身）。
|
||||
*/
|
||||
const ws = workspaceOf(exec);
|
||||
const scope = (mailSessionID ? `&session_id=${encodeURIComponent(mailSessionID)}` : '')
|
||||
+ (ws ? `&workspace=${encodeURIComponent(ws)}` : '');
|
||||
const { mails } = await client.get(
|
||||
`/mail/inbox?status=${status}&limit=${args.limit || DEFAULT_INBOX_LIMIT}${scope}`
|
||||
);
|
||||
|
||||
@ -32,9 +32,20 @@ test('★ 会话来源是平台上下文（并发安全），不是模块级变
|
||||
assert.ok(!bad.test(src), '不得用模块级"当前会话"变量（同进程多会话会互相覆盖）');
|
||||
});
|
||||
|
||||
test('取不到会话时退回整体收件箱（不猜）', () => {
|
||||
assert.match(src, /if \(!dshSessionId\) return ''/);
|
||||
assert.match(src, /const scope = mailSessionID \? `&session_id=[^`]*` : ''/);
|
||||
test('取不到会话时不猜（session 位与 workspace 位各自独立缺席）', () => {
|
||||
assert.match(src, /if \(!dshSessionId\) return ''/, '拿不到 DSH 会话 → 空串，不去反查');
|
||||
/*
|
||||
★★ 2026-09-26 这条断言改了：原来钉的是"取不到会话时退回**整体**收件箱"。
|
||||
那个"退回整体"正是缺陷 —— 在 mc 工作区干活的会话会因此拿到 agentmail 的信
|
||||
并照着去改 agentmail 的代码（用户当场指出）。
|
||||
|
||||
现在的规矩：两维**各自**缺席时各自不带，服务端对缺 workspace 直接 400。
|
||||
"错误可见"胜于"静默跨工作区"。（服务端那半见 workspace_scope_test.go）
|
||||
*/
|
||||
assert.match(src, /const ws = workspaceOf\(exec\);/,
|
||||
'workspace 要经 workspaceOf(exec) 取（与 mailSessionOf 同一把键）');
|
||||
assert.match(src, /ws \? `&workspace=\$\{encodeURIComponent\(ws\)\}` : ''/,
|
||||
'workspace 那维要真的拼进去');
|
||||
});
|
||||
|
||||
test('★ 判据自检：不带收窄的旧写法必须判红', () => {
|
||||
|
||||
Reference in New Issue
Block a user