76 lines
5.0 KiB
Markdown
76 lines
5.0 KiB
Markdown
# 二次对话必现中断问题排查记录
|
||
|
||
> 时间范围：2025-10-14 ~ 2025-10-15
|
||
> 调试参与者：Codex（AI 助手）
|
||
> 目标：定位并解决「在同一聊天中第二次发送消息必定失败」的问题
|
||
|
||
## 一、现象与初始假设
|
||
|
||
1. **复现特征**
|
||
- 第一次对话正常生成页面与 Section，并成功保存。
|
||
- 紧接着第二次对话必定失败，前端提示 `net::ERR_INCOMPLETE_CHUNKED_ENCODING` 或返回 502。
|
||
- 服务端日志显示 `request.signal` 被中止，随后触发 `/api/project` 保存失败并抛出 `P2003`。
|
||
|
||
2. **初步假设**
|
||
- 可能是浏览器主动 abort 导致 SSE 连接中断。
|
||
- 也可能是结构化摘要（structuredPageSnapshot）等辅助调用耗时太长，引发代理或服务器超时。
|
||
- `/api/project` 写库失败属于连锁反应，需要隔离观测。
|
||
|
||
## 二、针对性尝试与结果
|
||
|
||
### 1. 前端日志打点
|
||
- 为 `fetch`、`AbortController.abort`、`useChat` 状态变更以及 `stream-data` 增加详尽日志。
|
||
- 结果：确认 `ERR_INCOMPLETE_CHUNKED_ENCODING` 发生时，浏览器确实收到 200 响应头后被动断流；`AbortController.abort` 堆栈来自 Remix fetcher 的 `submit`（revalidation），并非我们主动调用。
|
||
|
||
### 2. 阻断 `/api/project` 的连锁影响
|
||
- 在 `useChatMessage.onFinish` 与 `useProject.saveProject` 中加入 `skipNextProjectSaveRef` 与 `getAborted()` 检查，避免失败时继续提交 `/api/project`，消除 `P2003` 噪声。
|
||
- 验证：失败后不再触发保存请求，日志干净。
|
||
|
||
### 3. 结构化摘要调用的中止处理
|
||
- 在 `structuredPageSnapshot` 周围增加 `AbortController`，尝试在前端 abort 时终止重试。
|
||
- 初始实现将自定义 `AbortError` 抛到外层，导致 Node 进程崩溃。修复后改用 `retry.AbortError` 并吞掉异常，确保只记录 warning，不崩溃。
|
||
|
||
### 4. 服务端额外日志与防护
|
||
- 捕获 `chatStreamText`、`structuredPageSnapshot` 的耗时及异常堆栈，判断是否是上游 LLM 调用超时。
|
||
- 在 `streamExecutor` 与 `chatStreamText` 内部检测 `request.signal.aborted` 后立即返回，防止中止后继续执行后续逻辑。
|
||
- 处理 `trust proxy` 设置，避免限流中间件报错阻塞服务启动。
|
||
|
||
### 5. 观察结果
|
||
- 中止场景下服务器不再崩溃，也不会触发 `/api/project`，但「第二次请求仍然被客户端中止」这一现象未根治。
|
||
- 前端控制台依旧会在第二轮输出 `ERR_INCOMPLETE_CHUNKED_ENCODING`，说明连接被关闭但没有崩溃日志。
|
||
|
||
## 三、现阶段确认的结论
|
||
|
||
1. **崩溃原因已排除**
|
||
- 之前 Node 进程重启是因为我们抛出的 `Error("客户端已中止…")` 浮出到最外层，现在已改为 `retry.AbortError` 并在 catch 内消化，服务端不会再因此崩溃。
|
||
|
||
2. **保存数据的连锁反应已阻断**
|
||
- 二次对话失败不会再触发 `/api/project` 的 500 与 `P2003`，数据库层面不受影响。
|
||
|
||
3. **核心断流仍存在**
|
||
- 浏览器在第二次流式请求开始不久就断开连接，`AbortController.abort` 的堆栈指向 Remix fetcher（revalidation）。
|
||
- `structuredPageSnapshot`（辅助模型调用）在每次中止时都会被打断，并记录 warning；但即便完全不保存也会早早中止，说明问题不在写库阶段，而是在请求处理链更早的位置。
|
||
|
||
## 四、待验证与下一步计划
|
||
|
||
1. **验证结构化阶段是否必要条件**
|
||
- 临时跳过 `structuredPageSnapshot` 和 `selectContext`，仅保留主模型回复，看二次对话是否仍断流。
|
||
- 若断流消失，则将进一步评估结构化内容的超时策略或输入长度限制。
|
||
|
||
2. **获取 Abort 堆栈**
|
||
- 在浏览器控制台记录 `[AbortController.abort]` 的堆栈（我们已注入补丁），用于确认到底是 Remix fetcher 还是其他逻辑主动取消请求。
|
||
- 若堆栈指向 Remix revalidation，可考虑调整 Remix 的 `shouldRevalidate` 或 fetcher 调用时机。
|
||
|
||
3. **查看上游网络/代理**
|
||
- 目前日志没有出现 502，但仍报 `ERR_INCOMPLETE_CHUNKED_ENCODING`，需要确认 Docker/宿主机是否存在连接重置（本地端口、代理等）。
|
||
- 可以通过 `curl -N` 直接请求 `/api/chat` 进行 CLI 流式验证，排除浏览器因素。
|
||
|
||
4. **针对 HTML 解析警告**
|
||
- 第二轮响应中模型返回了不完整的 `<script>` 与 `<section>`，导致前端解析失败。虽与断线无直接关系，但可能触发某些保护性中止，需在后续排查中一并关注。
|
||
|
||
## 五、总结
|
||
|
||
目前的改动保证了服务端在异常情况下不会崩溃，也不会误写数据库。但核心问题是客户端在第二轮请求时仍旧提前关闭连接（表现为 `ERR_INCOMPLETE_CHUNKED_ENCODING`）。
|
||
|
||
下一步的核心工作是找出“谁”触发了 `AbortController.abort()`，并验证是否与结构化辅助步骤相关。待上述验证完成后，再恢复辅助功能并优化网络策略，才能真正实现「第二次对话不再失败」的目标。*** End Patch
|