247 lines
10 KiB
Markdown
247 lines
10 KiB
Markdown
## CamTalk 对话历史功能 — Bug 分析与修复方案
|
||
|
||
### 一、整体架构现状
|
||
|
||
当前对话历史系统存在一个**根本性的架构缺陷**：前端和后端各自维护了一套完全独立的会话管理系统，两者之间从未同步。
|
||
|
||
**前端**：`useSessionList` Hook + `localStorage` 管理会话列表和消息存储。会话 ID 由前端 `uuid` 生成，消息通过 `localStorage` 持久化。
|
||
|
||
**后端**：`MemoryManager` (内存) + `PgSessionRepository` / `PgMessageRepository` (PostgreSQL) 管理会话和消息。会话 ID 由后端 `uuid.New()` 生成。
|
||
|
||
前端 `api.ts` 中没有任何对话相关的 REST API 调用，后端提供的 `/api/conversations` 全套接口（List / Create / Get / Patch / Delete / GetMessages）完全未被前端使用。
|
||
|
||
---
|
||
|
||
### 二、Bug 清单
|
||
|
||
#### P0 — 严重级别
|
||
|
||
**Bug 1：前后端会话系统完全脱节**
|
||
|
||
前端创建会话（`useSessionList.createSession`）只在 localStorage 中写入一条 `SessionSummary`，后端完全不知道这个会话的存在。后端在 WebSocket 连接时创建的会话（`ws/handler.go` L148）有独立的 ID，前端也无法感知。两套 ID 体系互不关联，导致：
|
||
|
||
- 前端切换/删除会话无法影响后端
|
||
- 后端消息持久化到 PG 但前端无法读取
|
||
- 对话历史不能跨设备、跨浏览器同步
|
||
- 清除浏览器数据后所有历史丢失
|
||
|
||
**Bug 2：活跃对话中创建/切换会话导致后端消息写入错误会话**
|
||
|
||
复现步骤：
|
||
1. 用户在会话 A 中正在对话（WebSocket 已连接，后端 sessionID = A）
|
||
2. 用户点击"新建对话"
|
||
3. 前端 `handleNewSession` 调用 `createSession()` 创建前端会话 B，调用 `setMessages([])` 清空 UI
|
||
4. 由于 `connectionStatus === "connected"`，调用 `stopSession()` 断开 WebSocket
|
||
5. 用户在新 UI 中发送消息，前端显示在"新对话"下
|
||
6. 但 WebSocket 重连后，后端创建了一个**全新的**会话 C
|
||
|
||
结果：前端认为是会话 B，后端实际是会话 C。如果 `stopSession` 未执行（连接状态判断时序问题），消息甚至会写入旧会话 A。
|
||
|
||
**Bug 3：刷新页面后 activeSessionId 丢失，消息无法自动保存**
|
||
|
||
`useSessionList` 中 `activeSessionId` 初始值为 `null`，且不会从 localStorage 恢复：
|
||
|
||
```typescript
|
||
const [activeSessionId, setActiveSessionId] = useState<string | null>(null);
|
||
```
|
||
|
||
初始化逻辑（`App.tsx` L122-129）仅在 `sessions.length === 0` 时调用 `createSession()`。对于回访用户（sessions 不为空），`activeSessionId` 保持 `null`。
|
||
|
||
自动保存的 `useEffect`（L136-140）需要 `activeSessionId` 非 null：
|
||
|
||
```typescript
|
||
if (activeSessionId && messages.length > 0) {
|
||
persistSession(activeSessionId, messages);
|
||
}
|
||
```
|
||
|
||
结果：回访用户如果不点击侧边栏选择会话，所有新消息不会被持久化，刷新页面即丢失。
|
||
|
||
#### P1 — 重要级别
|
||
|
||
**Bug 4：切换会话时强制断开 WebSocket，用户体验差**
|
||
|
||
`handleSelectSession` 和 `handleNewSession` 都调用 `stopSession()`，而 `stopSession` 会断开 WebSocket 连接。每次切换会话都需要重新建立连接（TCP 握手 + JWT 认证 + VAD 初始化），增加约 1-3 秒延迟。
|
||
|
||
正确做法应该是在切换会话时保持 WebSocket 连接，仅在后端切换 sessionID（通过发送 `conversation_id` 参数重连，或者在协议中增加切换会话的消息类型）。
|
||
|
||
**Bug 5：前端 historyRef 是无效的死代码**
|
||
|
||
`useVisionSession` 中的 `historyRef`（L48）被维护但从未被实际使用：
|
||
|
||
```typescript
|
||
const historyRef = useRef<Array<{ role: string; content: string }>>([]);
|
||
```
|
||
|
||
它被 push（`llm_done` 时 L258、`sendTextMessage` 时 L466、`interrupt` 时 L417），但从未被读取或发送到后端。前端的 LLM 上下文完全由后端 `session.Manager.GetHistory` 独立管理。这段代码增加了维护负担却没有任何功能价值。
|
||
|
||
**Bug 6：VAD 语音输入时用户消息未加入 historyRef**
|
||
|
||
`onSpeechEnd` 回调（L186-228）添加了用户消息到 `messages` state，但从未 push 到 `historyRef`。同样，`stt_result` 处理器（L236-249）更新消息文本后也未同步到 `historyRef`。
|
||
|
||
虽然 `historyRef` 本身是死代码（Bug 5），但如果未来要利用它，这个遗漏会造成语音消息在前端历史中缺失。
|
||
|
||
**Bug 7：观察模式消息未加入 historyRef**
|
||
|
||
`useObservationMode` 的 `onChange` 回调（L82-107）添加了用户消息但未 push 到 `historyRef`。同 Bug 6。
|
||
|
||
#### P2 — 一般级别
|
||
|
||
**Bug 8：ChatPanel 使用数组 index 作为 React key**
|
||
|
||
```tsx
|
||
{messages.map((msg, index) => (
|
||
<div key={index} ...>
|
||
```
|
||
|
||
当消息列表动态变化时（如 STT 结果更新替换了占位消息），使用 index 作为 key 可能导致 React 无法正确 diff，出现闪烁或渲染异常。应使用稳定唯一的 ID（如 `timestamp` 或生成 UUID）。
|
||
|
||
**Bug 9：后端 AppendMessage 中 tokensUsed 始终为 0**
|
||
|
||
`MemoryManager.AppendMessage` 异步写 PG 时硬编码 `tokensUsed` 为 0：
|
||
|
||
```go
|
||
if err := m.msgRepo.SaveMessage(context.Background(), sessionID, msg, 0); err != nil {
|
||
```
|
||
|
||
`WsLLMDone` 中的 `tokens_used` 信息未被传递到持久化层，导致 PG 中所有消息的 token 统计均为 0。
|
||
|
||
**Bug 10：后端 WS Handler 与 Eino 编排器重复获取历史**
|
||
|
||
`handler.go` L240 获取了 `history` 并传给 `ProcessQuery`，但 `ProcessQuery`（`adapter.go`）内部并未使用这个参数。Eino Graph 的 History 节点（`nodes_history.go`）会自己重新调用 `sessionMgr.GetHistory`。传入的 `history` 参数被浪费了一次查询。
|
||
|
||
**Bug 11：后端 GetMessages 内存 fallback 的 beforeID 语义不一致**
|
||
|
||
PostgreSQL 实现中 `beforeID` 是消息 ID 游标（`WHERE id < $2`），而内存 fallback 将其当作数组索引偏移量：
|
||
|
||
```go
|
||
if beforeID > 0 && int(beforeID) <= total {
|
||
allMessages = allMessages[:beforeID]
|
||
}
|
||
```
|
||
|
||
两种实现的语义完全不同，切换存储后端时分页行为会不一致。
|
||
|
||
---
|
||
|
||
### 三、修复方案
|
||
|
||
#### 方案核心思路
|
||
|
||
将前端会话管理从 localStorage 迁移到后端 API，实现单一数据源。前端变为"薄客户端"，会话 CRUD 和消息持久化全部走后端 `/api/conversations` 接口。
|
||
|
||
#### Phase 1：前端对接后端 API（解决 P0 Bug 1/2/3）
|
||
|
||
**1.1 在 api.ts 中增加对话 API 封装**
|
||
|
||
```typescript
|
||
// 新增对话 API
|
||
export async function listConversations(token: string, page = 1, size = 20) { ... }
|
||
export async function createConversation(token: string, config?: SessionConfig) { ... }
|
||
export async function getConversationMessages(token: string, id: string) { ... }
|
||
export async function deleteConversation(token: string, id: string) { ... }
|
||
export async function renameConversation(token: string, id: string, title: string) { ... }
|
||
```
|
||
|
||
**1.2 重写 useSessionList Hook**
|
||
|
||
将所有 CRUD 操作从 localStorage 切换到后端 API：
|
||
|
||
- `createSession` → `POST /api/conversations`
|
||
- `deleteSession` → `DELETE /api/conversations/:id`
|
||
- `renameSession` → `PATCH /api/conversations/:id`
|
||
- `selectSession` → `GET /api/conversations/:id/messages`
|
||
- 初始化时 → `GET /api/conversations` 加载列表
|
||
- 移除 `saveSessionMessages` / `loadSessionMessages` 等 localStorage 操作
|
||
- 将 `activeSessionId` 持久化到 localStorage（仅用于恢复选中状态）
|
||
|
||
**1.3 初始化逻辑修复**
|
||
|
||
```typescript
|
||
useEffect(() => {
|
||
if (!initializedRef.current) {
|
||
initializedRef.current = true;
|
||
if (sessions.length === 0) {
|
||
createSession();
|
||
} else {
|
||
// 恢复上次选中的会话
|
||
const lastId = localStorage.getItem('camtalk:last_active_session');
|
||
if (lastId && sessions.find(s => s.id === lastId)) {
|
||
setActiveSessionId(lastId);
|
||
}
|
||
}
|
||
}
|
||
}, [sessions.length, createSession]);
|
||
```
|
||
|
||
#### Phase 2：WebSocket 会话切换（解决 P0 Bug 2, P1 Bug 4）
|
||
|
||
**2.1 WebSocket 连接增加 conversation_id 参数**
|
||
|
||
后端已支持 `conversation_id` 查询参数（`handler.go` L126-133），前端需要在 `connect` 时传入当前会话 ID：
|
||
|
||
```typescript
|
||
connect(token?: string, conversationId?: string): void {
|
||
const params = new URLSearchParams();
|
||
if (token) params.set('token', token);
|
||
if (conversationId) params.set('conversation_id', conversationId);
|
||
const url = `${WS_URL}?${params.toString()}`;
|
||
// ...
|
||
}
|
||
```
|
||
|
||
**2.2 切换会话时保持连接**
|
||
|
||
在 `handleSelectSession` 中，不再调用 `stopSession()`，而是：
|
||
1. 保存当前会话消息到后端（如果需要）
|
||
2. 断开当前 WebSocket
|
||
3. 用新会话 ID 重新连接
|
||
|
||
或者更优方案：在 WebSocket 协议中增加 `switch_session` 消息类型，允许在保持连接的情况下切换后端会话。
|
||
|
||
#### Phase 3：清理前端冗余代码（解决 P1 Bug 5/6/7, P2 Bug 8）
|
||
|
||
**3.1 移除 historyRef**
|
||
|
||
删除 `useVisionSession` 中的 `historyRef` 及其所有 push 操作。前端不再维护独立的 LLM 上下文历史，完全依赖后端。
|
||
|
||
**3.2 消息列表使用稳定 key**
|
||
|
||
将 `ChatMessage` 类型增加 `id` 字段（UUID），在创建消息时生成，用作文本 diff 和 React key。
|
||
|
||
```typescript
|
||
export interface ChatMessage {
|
||
id: string; // 新增
|
||
role: "user" | "assistant" | "system";
|
||
content: string;
|
||
// ...
|
||
}
|
||
```
|
||
|
||
#### Phase 4：后端修复（解决 P2 Bug 9/10/11）
|
||
|
||
**4.1 传递 tokensUsed 到持久化层**
|
||
|
||
修改 `AppendMessage` 接口，增加 `tokensUsed` 参数；或在 `EinoOrchestrator.ProcessQuery` 中，在 `llm_done` 后单独调用一次 `UpdateMessageMeta` 更新 token 信息。
|
||
|
||
**4.2 移除 WS Handler 中多余的 GetHistory 调用**
|
||
|
||
删除 `handler.go` L240 的 `history` 获取，同时从 `ProcessQuery` 签名中移除 `history` 参数。
|
||
|
||
**4.3 统一 GetMessages beforeID 语义**
|
||
|
||
内存 fallback 中改为基于消息序号的偏移量，或直接移除内存 fallback（生产环境始终使用 PG）。
|
||
|
||
---
|
||
|
||
### 四、实施优先级
|
||
|
||
| 优先级 | 修复项 | 预估工作量 |
|
||
|--------|--------|-----------|
|
||
| P0 | 前端对接后端 API + 初始化修复 | 2-3 天 |
|
||
| P0 | WebSocket 会话切换 | 1-2 天 |
|
||
| P1 | 清理 historyRef 死代码 | 0.5 天 |
|
||
| P2 | React key + tokensUsed + GetMessages | 1 天 |
|
||
|
||
总计约 5-7 天可完成全部修复。Phase 1 是核心，完成后对话历史功能即可正常工作。
|