feat(adopt): 邮件可投进平台上已存在的会话（TUI 与邮箱同一入口）
人在平台界面（pi TUI / opencode / DSH GUI）里开的会话，此前无法被邮件投进去。 补全早就把它们列为候选（agent_platform_sessions 镜像，插件心跳上报）， 但投递侧的 FindNamedSessionFor 只查 sessions 表 —— 选中后只能得到 404。 候选列表在承诺一件做不到的事。 TUI 与邮箱是同一个 Agent 的两个入口，不是两套隔离的世界。 ## Gateway sessions 表加 platform_id 列 + 部分索引。resolveTarget 的 SessionNamed 分支 本侧查不到时再查镜像，命中则「接管」：本侧建一条会话并绑定 platform_id， 之后每次投递都在 SSE 事件里带 platform_session_id。 - FindPlatformSession(agent, slug, workspace) 查镜像 - FindSessionByPlatformID 防重复接管（一条平台会话只能被接管一次， 否则同一条对话在邮箱里裂成多条互不相干的线索） - AdoptPlatformSession 建会话 + 绑定 + 别名复用平台 slug（撞名自动加后缀） - PlatformIDOf 供 notifyRecipients 读 三处语义决定： - workspace 以平台会话为准（它的 cwd 创建时就定了）。地址 path 位不同则不命中， 否则邮件会投进另一个项目的会话 - 主题优先用平台侧标题（它代表整条对话在谈什么，也是补全里显示的） - 接管计入 AllowNewSession 速率限制 —— 镜像里可能有几百条 slug， 不计的话它是绕过限流的后门 ## 插件 字段解析与失败话术抽成共用模块 lib/adopt.js（三方逐字节相同 + 进同源校验）： 字段名各写一遍时少个下划线就静默退化成「每封邮件新开一条」，而那个错误不抛异常。 - opencode：session.get 确认存在 → 照常 promptAsync（服务端持有会话，单一写者） - DSH：复用 startAgent 的 resume 分支，会话 id 换成平台自己那个； 界面上正开着时直接 followup（两个 handle 会各自写日志，replay 过不去） - pi：SessionManager.open(file) → 跑一轮 → dispose，不放进长期缓存 pi 必须短暂持有：SDK 无任何锁机制（flock/lockfile 命中 0），活着的 SessionManager 不 watch 文件 —— 外部追加的行看不见，算出的 parentId 指向 对方不知道的 entry，会话树分叉。写入是纯 append 所以文件不会坏。 配套三处：isStreaming 时不释放（否则杀掉排队中的下一封）、兜底计时器 （轮次超时 ×2，unref）、接管会话跳过命名同步。 最后一条是实测撞出来的：别名撞名时 Gateway 加后缀，而定稿别名又回写进 pi 会话文件 → 下次心跳上报的 slug 变成带后缀那个，人从补全里选的名字凭空消失。 opencode/DSH 无此环（它们的 slug 只读不写）。 接管后必须加入 mailDriven 集合，否则邮件投进去了却永远没有回音。 ## 迁移顺序 idx_sessions_platform 不能写在 init_sqlite.sql 里：那个脚本在 addMissingColumns 之前执行，而已部署的库里 sessions 表已存在 （CREATE TABLE IF NOT EXISTS 不补列）→ 索引建在不存在的列上， 整个迁移中断、服务起不来（生产实测）。依赖补出来的列的索引一律放 migrate.go 的 sqliteAddIndexes。PG 侧用 ALTER TABLE ADD COLUMN IF NOT EXISTS。 ## 生产验证 - pi × 2（agent-only-chain / mail-probe-alias）、opencode（glowing-moon）、 dsh（查看工程与插件适配指南）四条链路接管成功 - dsh 那次回信准确说出了界面上聊过的内容 → 上下文确实装回来了 - 第二封复用同一条本侧会话，平台侧无新增改名条目 - 回归：opencode 普通 .new + 别名续谈 + used_rounds=0（免配额通道未受影响） ## 其他 pi-mail-bridge 补 systemd 单元（此前是 setsid 裸进程，重启机器不会拉起）： 陈锁清理 ExecStartPre、MemoryMax=4G、TimeoutStopSec=10。 配置目录必须与 opencode 分开（共用会让后起的读到对方密钥或撞单实例锁）。 PLUGIN-CONTRACT.md 加 B-3.7 / B-3.8 + new_mail 字段表 + 检查清单验收项。 测试：repo +10 例（adopt_test.go）；三插件各 +7 例（adopt.test.mjs）
This commit is contained in:
@ -34,6 +34,7 @@ import { modelAttemptOrder, renderFailureReport, snapshotPiModels } from '../lib
|
||||
import { snapshotPiSessions } from '../lib/session-snapshot.js';
|
||||
import { selectCatchup } from '../lib/catchup.js';
|
||||
import { explicitSends, shouldSkipAutoRelay } from '../lib/relay-dedup.js';
|
||||
import { adoptedSessionID, adoptMissingMessage } from '../lib/adopt.js';
|
||||
import { createGrantStore, isApproval } from '../lib/permission-grants.js';
|
||||
|
||||
// ─── 配置 ───
|
||||
@ -254,6 +255,159 @@ function piMailFallback(sessionKey) {
|
||||
return join(homedir(), '.pi', 'mail-sessions', String(sessionKey || 'default'));
|
||||
}
|
||||
|
||||
/**
|
||||
* 接管过的 pi 会话（pi session id）。用完即释放，见 releaseAdopted。
|
||||
*
|
||||
* 与 `sessions` 的区别：那里存的是桥自己起的、长期持有的会话；这里是
|
||||
* 「借用一下磁盘上人家的会话」，一轮结束就还回去。
|
||||
*/
|
||||
const adopted = new Set();
|
||||
|
||||
/** 接管会话的兜底释放计时器（pi session id -> Timeout）。 */
|
||||
const adoptTimers = new Map();
|
||||
|
||||
/**
|
||||
* 接管会话最长持有多久。
|
||||
*
|
||||
* 取轮次超时的两倍：`runTurn` 60 秒就按成功返回（长任务很正常，判成失败会
|
||||
* 换模型重跑一遍），但会话仍在跑。正常结束走 agent_end 提前释放，这个数字
|
||||
* 只兜「事件永远不来」的底。
|
||||
*/
|
||||
const ADOPT_MAX_HOLD_MS = TURN_TIMEOUT_MS * 2;
|
||||
|
||||
/**
|
||||
* 接管一条磁盘上已经存在的 pi 会话，把这封邮件投进去。
|
||||
*
|
||||
* # 为什么必须**短暂持有**
|
||||
*
|
||||
* pi 没有任何锁机制，它假定「一个文件一个持有者」。活着的 SessionManager
|
||||
* 不 watch 文件：外部（TUI）追加的行它看不见，之后它自己的写入算出的 parentId
|
||||
* 指向一个对方不知道的 entry —— 文件不会坏（写入是纯 append），但会话树分叉。
|
||||
*
|
||||
* 所以这里 open → 跑一轮 → 丢弃，**不放进 sessions 长期缓存**。下一封邮件
|
||||
* 再来时重新 open，那一次读到的就是 TUI 期间写的全部内容。
|
||||
*
|
||||
* 窗口是一轮对话的时长。人正好在这期间也在 TUI 里发消息仍会分叉，但那需要
|
||||
* 两边同时动手，且后果是历史看起来少一段，不是数据损坏。
|
||||
*
|
||||
* # 为什么不校验「TUI 是否正开着这条会话」
|
||||
*
|
||||
* pi 不提供这个信息（没有 lockfile、没有 pid 记录）。能做的只有猜 mtime，
|
||||
* 而任何阈值都是猜。与其用一个猜出来的数字拒掉合法投递，不如让窗口尽量短。
|
||||
*/
|
||||
async function adoptSession(platformID, data, mailTools) {
|
||||
const mailSessionID = data.session_id;
|
||||
const { SessionManager } = await import('@earendil-works/pi-coding-agent');
|
||||
|
||||
// listAll 而不是 list(cwd)：桥的进程 cwd 与会话 cwd 无关。
|
||||
const all = await SessionManager.listAll();
|
||||
const info = all.find((e) => e?.id === platformID);
|
||||
if (!info?.path) {
|
||||
// 镜像是快照，可以过期：那条会话可能已经被删了。
|
||||
// **不能**退回「新建一条」—— 那会让人在 TUI 里看不到这封邮件带来的对话，
|
||||
// 而那正是接管的目的（N-8 同理：静默改语义比报错糟）。
|
||||
throw new Error(adoptMissingMessage(platformID, '磁盘上已无这个会话文件'));
|
||||
}
|
||||
|
||||
// cwd 取会话自己的（SessionInfo.cwd 来自持久化 header）。
|
||||
// 老会话的 cwd 是空串，那种情况退回地址里的 path 位。
|
||||
const { cwd } = resolveWorkspaceCwd(
|
||||
info.cwd || data.to_workspace, piMailFallback(mailSessionID));
|
||||
|
||||
const opened = await openSession({
|
||||
cwd,
|
||||
modelRuntime,
|
||||
customTools: mailTools,
|
||||
extension: permissionExtension((id) => mailContexts.get(id)),
|
||||
sessionFile: info.path,
|
||||
});
|
||||
for (const d of opened.diagnostics) {
|
||||
log(`扩展诊断: ${d?.message ?? JSON.stringify(d)}`);
|
||||
}
|
||||
|
||||
const piSessionId = opened.session.sessionId;
|
||||
const entry = { session: opened.session, sessionManager: opened.sessionManager, cwd };
|
||||
|
||||
if (mailSessionID) {
|
||||
sessions.set(mailSessionID, entry);
|
||||
reverseMap.set(piSessionId, mailSessionID);
|
||||
// 加进 mailDriven：接管之后这条会话**开始**参与邮件往来，轮次结束要把
|
||||
// 总结转回发件人。不加的话邮件投进去了却永远没有回音。
|
||||
mailDriven.add(piSessionId);
|
||||
adopted.add(piSessionId);
|
||||
}
|
||||
|
||||
// 兜底释放：`agent_end` 不来就永远握着这个文件，而握着它的期间 TUI 那边
|
||||
// 的写入对我们不可见 —— 正是要避免的分叉窗口。会话跑挂、事件丢失、
|
||||
// 模型一直不结束都属于这种情形。
|
||||
//
|
||||
// 时长取轮次超时的两倍：runTurn 自己 60 秒就按成功返回了（长任务很正常），
|
||||
// 那之后会话仍在跑，正常结束时 agent_end 会照常触发并提前释放。
|
||||
const safety = setTimeout(() => {
|
||||
if (!adopted.has(piSessionId)) return;
|
||||
log(`接管会话 ${piSessionId} 超过 ${ADOPT_MAX_HOLD_MS / 1000}s 未结束，强制释放`);
|
||||
releaseAdopted(piSessionId, mailSessionID);
|
||||
}, ADOPT_MAX_HOLD_MS);
|
||||
if (typeof safety.unref === 'function') safety.unref();
|
||||
adoptTimers.set(piSessionId, safety);
|
||||
|
||||
// 只挂 agent_end，不挂 session_info_changed：改名同步会把 Gateway 侧的别名
|
||||
// 覆盖成 pi 的标题，而接管会话的别名是人从补全里选的那个 slug ——
|
||||
// 改掉会让他找不到自己刚发的信。
|
||||
opened.session.subscribe((event) => {
|
||||
if (event?.type !== 'agent_end') return;
|
||||
if (event.willRetry) return;
|
||||
// 转发完再释放：relaySummary 要读 sessions 里的 entry。
|
||||
relaySummary(piSessionId)
|
||||
.catch((e) => log(`自动转发失败: ${describeError(e)}`))
|
||||
.finally(() => {
|
||||
// **还在跑就不能释放。**
|
||||
//
|
||||
// 同一条会话可能已经排了下一封邮件：runTurn 在 isStreaming 时走
|
||||
// `streamingBehavior: 'followUp'`，那封信排在当轮之后。此时 dispose
|
||||
// 会把排着的那一轮一起杀掉 —— 发件人只看到信发出去后再无音讯。
|
||||
// 排着的那轮结束时会再触发一次 agent_end，由它来释放。
|
||||
if (opened.session.isStreaming) {
|
||||
log(`接管会话 ${piSessionId} 仍有排队轮次，暂不释放`);
|
||||
return;
|
||||
}
|
||||
releaseAdopted(piSessionId, mailSessionID);
|
||||
});
|
||||
});
|
||||
|
||||
log(`接管 pi 会话 ${piSessionId}（cwd=${cwd}，文件 ${info.path}）`);
|
||||
// reused: true —— 这条会话有历史，提示词不该重新自我介绍，
|
||||
// 且 deliverMail 的续谈支不做模型降级（换模型要换会话，会丢掉整条上下文）。
|
||||
return { ...entry, reused: true };
|
||||
}
|
||||
|
||||
/**
|
||||
* 还回一条接管来的会话：dispose + 清缓存。
|
||||
*
|
||||
* mailDriven 不清：它同时喂给心跳快照的 mail_driven 标记，那条平台会话
|
||||
* 确实已经在邮件往来里了。reverseMap 也不清 —— 留着让迟到的事件能找到线索，
|
||||
* 而 relaySummary 在 entry 缺失时会自己早退。
|
||||
*/
|
||||
function releaseAdopted(piSessionId, mailSessionID) {
|
||||
if (!adopted.has(piSessionId)) return;
|
||||
adopted.delete(piSessionId);
|
||||
const timer = adoptTimers.get(piSessionId);
|
||||
if (timer) {
|
||||
clearTimeout(timer);
|
||||
adoptTimers.delete(piSessionId);
|
||||
}
|
||||
const entry = mailSessionID ? sessions.get(mailSessionID) : undefined;
|
||||
if (entry?.session?.sessionId === piSessionId) {
|
||||
sessions.delete(mailSessionID);
|
||||
}
|
||||
try {
|
||||
entry?.session?.dispose?.();
|
||||
} catch (e) {
|
||||
log(`释放接管会话失败（不影响后续）: ${describeError(e)}`);
|
||||
}
|
||||
log(`释放接管会话 ${piSessionId}（文件已交还，下一封邮件重新打开）`);
|
||||
}
|
||||
|
||||
/**
|
||||
* 找到（或建立）这封邮件该落进的 pi 会话。
|
||||
*
|
||||
@ -266,6 +420,13 @@ async function resolveSession(data, mailTools) {
|
||||
const bound = mailSessionID ? sessions.get(mailSessionID) : undefined;
|
||||
if (bound) return { ...bound, reused: true };
|
||||
|
||||
// 服务端说这条邮件会话**接管了平台上已经存在的那条会话**（人在 TUI 里开的
|
||||
// 那种）—— 投进它而不是新建。TUI 与邮箱是同一个 Agent 的两个入口。
|
||||
const adoptedID = adoptedSessionID(data);
|
||||
if (adoptedID) {
|
||||
return await adoptSession(adoptedID, data, mailTools);
|
||||
}
|
||||
|
||||
// cwd 取寻址里的 path 位（B-3.1）。校验走共用模块：目录不存在时**不创建**
|
||||
// （N-2：笔误会在磁盘上落下真目录，而 Agent 在里面一无所获），拒绝相对路径（N-3）。
|
||||
//
|
||||
@ -387,8 +548,21 @@ async function relaySummary(piSessionId) {
|
||||
// （实测过：第一封邮件跑通了，sessions.session_alias 仍是空串）。
|
||||
//
|
||||
// 放在转发**之前**：回信里会带上会话别名，收件人看到的第一封回信就能用它续谈。
|
||||
await syncNaming(piSessionId, entry.session.sessionName)
|
||||
.catch((e) => log(`命名同步失败: ${describeError(e)}`));
|
||||
//
|
||||
// **接管来的会话跳过这一步。**
|
||||
//
|
||||
// 它的名字是人在 TUI 里定的，也是他从补全里选中的那个 slug。同步会双向改坏它：
|
||||
// 别名撞上本侧已有会话时 Gateway 加后缀（`agent-only-chain` →
|
||||
// `agent-only-chain-2`），而定稿别名又会**回写进 pi 的会话文件** ——
|
||||
// 于是下一次心跳上报的 slug 变成加了后缀那个，人从补全里选的名字凭空消失。
|
||||
// 实测撞出来过一次。
|
||||
//
|
||||
// 接管会话的别名由服务端在接管时按 slug 定好（AdoptPlatformSession），
|
||||
// 这里不需要也不应该再动它。
|
||||
if (!adopted.has(piSessionId)) {
|
||||
await syncNaming(piSessionId, entry.session.sessionName)
|
||||
.catch((e) => log(`命名同步失败: ${describeError(e)}`));
|
||||
}
|
||||
|
||||
// 只取 type==='text' 的块（B-5.1 / N-6）：thinking 是思考过程，不是结论
|
||||
const text = lastAssistantText(entry.session.messages);
|
||||
|
||||
@ -24,7 +24,7 @@ import { createAgentSession, SessionManager, SettingsManager, DefaultResourceLoa
|
||||
* @param {(pi: any) => void} [opts.extension] 内联扩展工厂，用来挂 tool_call 权限钩子
|
||||
* @returns {Promise<{session: any, sessionManager: any, diagnostics: any[]}>}
|
||||
*/
|
||||
export async function openSession({ cwd, modelRuntime, model, customTools, extension }) {
|
||||
export async function openSession({ cwd, modelRuntime, model, customTools, extension, sessionFile }) {
|
||||
const agentDir = getAgentDir();
|
||||
const settingsManager = SettingsManager.create(cwd, agentDir);
|
||||
|
||||
@ -45,7 +45,28 @@ export async function openSession({ cwd, modelRuntime, model, customTools, exten
|
||||
});
|
||||
await resourceLoader.reload();
|
||||
|
||||
const sessionManager = SessionManager.create(cwd);
|
||||
// sessionFile 非空 = **接管一条磁盘上已经存在的会话**（人在 TUI 里开的那种）。
|
||||
//
|
||||
// `SessionManager.open` 把整条会话装回内存（历史消息、分支、标签都在），
|
||||
// 之后 prompt 就是在那条对话后面接着谈 —— 人在 TUI 里再打开它能看到
|
||||
// 邮件带来的这一轮。TUI 与邮箱是同一个 Agent 的两个入口。
|
||||
//
|
||||
// # 双写风险与它的边界
|
||||
//
|
||||
// pi 没有任何锁机制（SDK 里 flock/lockfile 命中为 0），它假定「一个文件
|
||||
// 一个持有者」。写入本身是纯 append（`_persist` → `appendFileSync`），所以
|
||||
// 两个持有者不会把文件截断；坏的是**各自的内存索引**：对方追加的行自己看不见，
|
||||
// 于是算出的 parentId 指向一个对方不知道的 entry，会话树分叉。
|
||||
//
|
||||
// 取舍是「短暂持有」：open → 跑一轮 → 丢弃这个 manager（调用方不缓存它）。
|
||||
// 窗口是一轮对话的时长。人正好在那一刻也在 TUI 里发消息仍会分叉 ——
|
||||
// 但那需要两边同时动手，而分叉的后果是历史看起来少了一段，不是数据损坏。
|
||||
//
|
||||
// cwd 用会话 header 里的（open 的第三参不传即取 header），不是外面传进来的：
|
||||
// 会话的工作目录在它创建时就定了，传一个不同的只会让项目级配置错位。
|
||||
const sessionManager = sessionFile
|
||||
? SessionManager.open(sessionFile)
|
||||
: SessionManager.create(cwd);
|
||||
const created = await createAgentSession({
|
||||
cwd,
|
||||
agentDir,
|
||||
|
||||
Reference in New Issue
Block a user