# 【缺陷反馈】Kimi 官方 App 移动端对话中「排队信息」卡死导致会话永久失效且后续输入无响应缺陷报告
- **报告编号**：BUG-KIMI-APP-QUEUE-STALL-20261001
- **生成日期**：2026-10-01
- **缺陷级别**：高危（P1 / Blocker - 导致当前对话生命周期完全阻断，用户会话挂死）
- **报告归属**：Kimi 官方产品与技术团队
- **反馈类别**：移动端核心交互 / 对话状态机异常 / 消息队列阻塞
-–
## 一、标题（一句话概括）
**Kimi 官方 App 对话中因「排队信息」卡住导致当前会话彻底失效，后续发送任何内容均无响应，必须手动删除卡死消息方可恢复。**
-–
## 二、平台与版本环境
- **受影响平台**：Kimi 官方 App（移动端，涵盖 iOS / Android 客户端环境）
- **客户端版本**：Kimi 官方移动端最新及主流公测版本（具体内部 Build 版本号待官方客户端日志核实）
- **网络环境**：标准蜂窝移动网络 / Wi-Fi 网络环境
- **服务端接口环境**：月之暗面（Moonshot AI）Kimi 核心对话服务端交互接口
-–
## 三、问题描述（忠实反映长官 10-01 口述事实）
根据长官 2026-10-01 亲历与口述事实，现象原样忠实记录如下：
1. **现象**：在 Kimi 官方 App 移动端日常使用中，对话窗口内会出现「排队信息」（即服务器高峰期、推理资源调配或高并发时前端呈现的排队排位类提示消息）发生卡住、停滞、状态未更新的情况。
2. **后果**：一旦该排队信息发生卡住，用户在输入框随后输入的任何文本、提问或指令均完全失效。前端与后端通信链路看似阻断，客户端不再对新输入产生任何有效响应，会话进入假死停滞状态。
3. **唯一恢复办法**：用户必须逐条定位并手动删除那些卡住的排队提示类消息；只有在将卡死的排队信息彻底清除干净后，客户端才能重新正常发送信息、唤醒后续对话。
-–
## 四、复现步骤（据用户反馈与实测链条整理）
> 注：本步骤基于长官口述现象与多轮实际交互链路结构化梳理，据用户反馈标注。
1. **步骤一（触发排队）**：
-
打开 Kimi 官方移动端 App，进入任意已有对话或新建对话会话；
-
在系统高负载时段或大模型推理队列繁忙时段，向 Kimi 连续或发起长文本/复杂推理提问；
-
界面上弹出或生成等待排队的提示卡片/排队占位消息（如「正在为您排队…」、「当前咨询人数较多，请稍候」等排队状态提示）。
2. **步骤二（状态卡死）**：
- 客户端由于网络微抖动、长连接心跳中断、SSE/WebSocket 队列推送帧丢失或服务端队列重置，该排队消息的状态未流转为「推理中」或「生成完成」，亦未触发任何超时兜底与重试机制，永久固化停留在「排队中」展示态。
3. **步骤三（后续阻断）**：
-
用户尝试在输入框继续输入补充说明、催促文本或全新问题并点击发送；
-
发送按钮虽有点击反馈或消息进入本地列表，但无法得到服务端任何响应，不会触发流式 Token 输出，会话彻底冻结。
4. **步骤四（手动解除）**：
-
用户长按卡住的排队消息或通过消息管理操作，将所有卡住的排队相关消息全部从聊天历史记录中执行「删除」；
-
删除完毕后再次在输入框输入文本并发送，对话立即恢复正常，服务端重新开始响应生成。
-–
## 五、预期行为（Expected Behavior）
1. **状态机自愈与兜底**：若出现排队队列异常、网络重连或服务端超时，排队消息应具备完善的客户端 TTL（超时生存时间）和心跳探测机制。超时后应自动展示「重试」、「网络异常，请轻触重试」或自动将排队状态回退/取消，绝不应永久卡死。
2. **消息管道无阻塞**：即便历史某条排队请求在后端掉线或由于某种原因未得到响应，客户端的消息发送队列不应被前序异常请求全局死锁（Head-of-Line Blocking）。用户随后的新消息应能够作为新的一轮独立上下文请求正常上行并接收服务。
3. **清晰的交互引导**：若前序请求仍在排队中且客户端禁止并发提问，应在输入框给出明确置灰引导（例如「前序回答生成中，请稍候」），并在检测到前序状态僵死超过阈值（如 30 秒）时主动释放锁。
-–
## 六、实际行为（Actual Behavior）
1. **会话死锁**：排队提示消息卡在界面后，客户端本地状态机将该会话永远标记为「正在处理/排队等待回应」，导致整个会话上下文陷入死锁。
2. **静默丢弃/吞没用户输入**：用户随后发送的任何消息既无明确报错提示，也无法得到处理，用户体验呈现为「App 无响应」、「坏掉」、「发不出去」。
3. **强依赖用户逆向探索 Workaround**：普通用户无法理解底层逻辑，大多会误以为 App 崩溃或服务彻底不可用从而放弃使用。只有极少数发现隐藏规律的高级用户通过手动删除卡死消息才能恢复正常。
-–
## 七、临时规避措施（Workaround）
- **具体操作**：
1. 在发生卡死的对话界面中，长按卡住的排队提示类消息；
2. 在弹出的操作菜单中选择「删除」；
3. 若有多条相关的排队或未完成消息，将它们全部删除；
4. 确认卡死消息清空后，在输入框重新输入文字发送，即可唤醒对话。
-–
## 八、技术根因推测与排查建议（供 Kimi 研发团队参考）
1. **移动端本地状态机（Chat State Machine）死锁**：
-
客户端可能维护了一个 `isProcessing` 或 `pendingQueueTaskId` 状态变量。当排队消息被插入时，该标志位置为 `true`。
-
由于长连接中断（SSE 断开、WebSocket Close Code 未能正常派发、网络切换）、或者服务端排队调度服务将该任务从 Redis/Kafka 丢弃后未下发终态通知，客户端永远未收到 `ON_COMPLETE` 或 `ON_ERROR` 事件。
-
导致本地标志位永远为 `true`，后续所有 `sendMessage` 调用在本地校验层直接被忽略或挂起。
2. **本地数据库/缓存级联状态绑定**：
-
为什么用户必须「删除卡住消息」才能恢复？
-
这强烈表明：本地 SQLite / Room / CoreData 数据库中，卡住的消息记录被赋予了某种未决状态（如 `PENDING_QUEUE`）。在用户发送下一条消息时，客户端逻辑会查询历史消息最后一条的状态，若最后一条仍为 `PENDING`，则认为前序流水未结束；只有物理删除该条记录后，最后一条有效记录恢复为完成态（`SUCCESS`），逻辑锁得以释放。
3. **修复建议**：
-
**增加超时熔断机制**：排队状态设定严格的客户端超时（如 45 秒），超时未收到心跳包自动转为失败态并提供「重试」与「取消」按钮；
-
**解耦消息队列锁定**：禁止前序排队消息对后续全新发送操作形成无限期全局阻断；
-
**重连校验协议**：当应用冷启动、前后台切换或网络重连时，向服务端主动同步一次该 session 的在途任务状态，若服务端已无对应队列任务，立即在本地将该卡滞消息标记为已失效。
-–
## 九、影响面评估
- **受影响用户**：所有在高峰期或网络切换时段使用 Kimi 官方移动端 App 的高频用户；
- **业务危害**：导致用户对话被迫中断，严重拉低产品口碑；极易被用户误判为 Kimi 整体系统宕机，造成用户流失；
- **排查优先级**：建议作为客户端核心交互体验 P1 缺陷紧急排查并发布热更修复。