Files
HomeAgent/internal/plugins
JianFeeeee 134cd860b6 fix(webui): 聊天受理超时 15s 太短,误报「已取消(用户停止)」
## 内测用户报告

发一句话,界面回「已取消(用户停止)」,而且连着出现多次。

## 实测真相(用户提供的日志)

    20:58:36  POST /api/v1/chat 开始,agent 开始干活
    20:58:48  agent 仍在跑(terminal_create / terminal_read)
    20:58:52  ★ 前端 15s ackTimer 到点 → ctrl.abort()
              → 服务端记 status=504,耗时 15.89s
    20:59:29  ★ agent 正常跑完,52.5 秒、22 个工具、返回 response

也就是说:**agent 从来没有被取消过**。它一直在正常干活并跑完了,
只是前端自己掐断了连接,回复没法送回,UI 就把"我没等到"显示成了
"用户停止"——一个用户从没做过的操作。

## 根因

`sendChat()` 里把"受理确认"的等待写死 15 秒,而 agent 的正常任务
动辄 45-55 秒(工具越多越久;同一份日志里另一次是 45262ms)。

这个 POST 本来就是**触发式**的:真正渲染靠 SSE 流式(`armTurnWatchdog`
兜 120 秒)。在受理环节抢时间没有任何意义,只会误伤正常任务。

## 改动

1. **超时 15s → 600s**:不再用固定短超时。保留上限只为兜住
   "连 TCP 都建不起来"这类真故障,避免请求永远挂着。

2. **文案改掉**:原来 abort 后提示「请求超时(可能已发送)」,
   红字 error 样式。用户看到"超时"会以为消息丢了而**重发** ——
   实测会造成同一句话产生两条任务。改为:
   「已发出,AI 正在处理(复杂任务可能要一两分钟)。请等待回复,不要重复发送。」
   并且不再用 error 样式(这不是错误)。

## 判据(2 条,源码扫描)

 · `TestChatAckTimeoutIsGenerous`:超时 ≥ 5 分钟
   (实测正常任务 45-55 秒,留足余量)
 · `TestChatAckTimeoutMessageDoesNotBlameFailure`:提示不得出现
   "失败/超时/Error/failed",必须说清"正在处理"且提醒"不要重发"

变异 2/2 咬住(改回 15s / 改回"请求超时"文案都当场变红)。

★ 为什么用源码扫描而不是行为测试:这是前端 abort 时序,没有可注入的
  时钟。扫描至少能防住"有人把 15s 改回来"。
2026-10-17 21:16:49 +08:00
..