群组话题消息服务端已留存但客户端不渲染：尾部历史不可见，新发消息即隐形（v2.2.15 正式版可复现）

快速结论：该现象通常出现在包含 supervisor 与组员的多 agent 群组话题中，表现为服务端已完整留存消息、但客户端在某个边界（如第 160 条）之后不再渲染历史，断点之后新发消息也立即不可见。优先排查消息查询路径中 groupId 是否被正确传递，而不是先怀疑数据丢失。

适用环境：LobeChat v2.2.15 正式版（2026-08-29 实测复现），已知最早在 v2.2.15-canary.60 观察到；客户端类型为 Desktop App (Electron) 与 Web（桌面浏览器），操作系统 macOS，浏览器 Safari，部署平台为 Official Cloud。Issue 未确认更早受影响版本。

最快修复方案：暂无确认的一步修复方案。Issue 报错原文 parent message no longer exists 在全仓库检索 0 覆盖（实际代码中措辞不同），v2.2.15 正式版 changelog（#18747）未包含相关修复，关联的 #18497 经实测只修复“发送被死锁拦截”路径，UI 依旧不渲染。

注意事项：Issue 中的机制分析（groupId 缺失导致查询落入 groupId IS NULL 分支）来自维护者评论的推断，并非最终确认结论。在官方修复前，请勿删除话题或重新导入数据，以免丢失服务端仍完整的 185 条记录。

问题场景

用户在 LobeChat v2.2.15 中打开一个多 agent 群组话题（supervisor + 组员，示例话题 tpc_dzi4GOMAmh03），该话题服务端共 185 条记录。客户端（桌面端与网页端一致）仅渲染前 160 条，尾部 25 条（assistant 13 / tool 11 / user 1）不可见；在断点之后新发送的任何消息（包括纯文本探针 hello?）发出后立即不可见。同型现象还包括：组员被单独召唤时回复执行完成后不显示（supervisor 与组员本人都看不到，无报错提示），话题在侧边栏持续显示“思考中”转圈但生成实际已停止。

关键证据是四通道对照：客户端 UI 仅前 160 条；getTopicContext / lh topic view --limit 500 可见全量 185 条；lh message list --topic-id <id> 返回空（对健康话题正常返回）；桌面端“话题导出”得到 185 条完整内容。数据侧 185 条单根连通、孤儿 0、时间倒挂 0，首条不可见消息的 parentId 恰好是最后一条可见消息，截断点与数据连续性完全吻合。

报错原文

parent message no longer exists — likely deleted while the operation was running

维护者指出，代码库中实际措辞略有不同，为插值形式（在 apps/server/src/modules/AgentRuntime/messagePersistErrors.ts 中）：

Conversation parent message ${parentId} no longer exists. It was likely deleted while the operation was running.

原因分析

可能原因（据 Issue 评论分析，尚未最终确认）：MessageModel.query() 会分派到三个互斥分支——thread 分支（设置 threadId 时完全绕过群组逻辑）、group chat 分支（设置 groupId 时按 groupId + topicId 过滤，刻意不应用 agentId）、standard 分支（未传 groupId 时回落到 matchGroup(groupId)，即 groupId IS NULL，从而排除所有 group_id 非空的消息）。

如果读取或写入链路上任一调用方遗漏了 groupId（或传了 agentId 替代），查询就会进入 standard 分支，对一个所有消息 group_id 均非空的话题静默返回零行。这一缺陷类型在历史上已多次复现（PR #16154、#16313、#16289 均属同类修复）。这也能解释 CLI 证据的分歧：lh topic view 走 queryTopicTranscript，仅按 topicId 过滤、无群组/agent 作用域，因而能看到全部 185 条；而 lh message list 走标准 query() 路径，对无 groupId 的群组话题落入 groupId IS NULL 分支，返回空。

分页逻辑也可能叠加影响：读取路径默认取最新 1000 条，页满时会把下边界裁剪到最近的 user 角色轮次起点。185 条本不应触发，但与群组作用域不匹配叠加时可能加剧可见截断。

环境排查

确认 LobeChat 版本：是否为 v2.2.15 正式版，或 v2.2.15-canary.60 / canary.65 等已知可复现版本。
确认客户端类型：Desktop App (Electron) 与 Web 是否双端一致复现。
确认操作系统与浏览器：Issue 环境为 macOS + Safari。
确认部署平台：Official Cloud（云部署）。
确认话题类型：是否为含 supervisor + 组员调用的多 agent 群组话题（同期未调用组员的单聊话题无异常，此为相关性观察，非因果结论）。
对照检查服务端数据完整性：使用 lh topic view <topicId> --limit 500 核对总条数，并检查 lh message list --topic-id <id> 对健康话题与异常话题的返回差异。
确认消息记录中 group_id 是否均非空，以及客户端查询请求是否携带 groupId。
Issue 未提供具体 Python、CUDA、PyTorch、显卡或依赖版本信息，无需补测这些项目。

解决步骤

先按四通道对照确认“服务端已留存、客户端不渲染”这一特征：用 lh topic view <topicId> --limit 500 查看全量条数，与客户端 UI 可见条数比对。
用桌面端“话题导出”导出该话题，核对总条数、正文内容与父链完整性，确认存储层无断裂（预期为 185 条、孤儿 0）。
对同一话题执行 lh message list --topic-id <topicId>，观察是否返回空；再对一个健康话题执行同一命令作为对照。
若确认属于群组话题且 lh message list 返回空，记录该话题 ID、服务端总条数、客户端可见条数与首个不可见消息的 parentId，作为定位 groupId 缺失点的证据。
登录 Issue #18806 提供上述结构化信息（消息 id / parentId / role / 时间戳 / 长度，正文可脱敏），并说明可协助复现与测试修复。
在官方修复发布前，暂不要删除话题或重新导入数据。

验证方法

修复到位后，同一群组话题应满足：客户端 UI（桌面端与网页端）渲染全部 185 条历史；在断点之后发送的新消息发出后立即可见；组员被单独召唤的回复在 supervisor 与组员本人都可见；话题在侧边栏不再持续显示“思考中”转圈。同时 lh message list --topic-id <topicId> 对群组话题恢复返回结果，与 lh topic view 的条数一致。