TUI: rejected /new and /clear lose input after lazy session assembly
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 60/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
- 领域
- cli
调研方向
从 apps/kimi-code/src/tui/commands/dispatch.ts 约第 383-399 行开始，该处 /new 和 /clear 在组装后的忙碌分支会显示错误并返回，而不恢复输入，将其与现有的 canRestoreSubmittedInput 守卫进行比较。通过编辑器路径（v2 引擎）运行 apps/kimi-code/test/tui/kimi-tui-message-flow.test.ts 中的 blocks /new 用例。完成标准是：被拒绝的命令仅在编辑器仍为空且未打开任何面板时才返回编辑器，并且较新草稿和已打开面板的检查仍然通过。在维护者 /approve 之前，不要开启 PR。
由索引模型根据 Issue 内容生成。
描述
What version of Kimi Code is running?
Source checkout f28c51c01f025bba9f0d0f58f6309e7517a8cd02; affected dispatch and test unchanged at main d4b9dc4a2d6ff72413964feda2563f0adf8e04d2
Which open platform/subscription were you using?
Not applicable: registered local TUI component tests, no provider request or login needed
Which model were you using?
No real model call; deferred test session
What platform is your computer?
Linux x86_64, Node.js 24.19.0, pnpm 10.33.0
What issue are you seeing?
If /new or /clear is submitted while first-use session creation is pending, the first prompt can start streaming before the command resumes. The command correctly reports "Cannot /new while streaming", but the editor stays empty instead of restoring the rejected input.
The synchronous busy gate and the delayed session-requiring-command branch already restore rejected input. The post-assembly busy branch for /new only shows the error and returns.
What steps can reproduce the bug?
- Start the TUI without an active session and submit a first prompt.
- While lazy session creation is pending, submit /new (or /clear).
- Let that session finish assembly and the first prompt start streaming.
- Observe the busy error and the empty editor.
Deterministic component reproduction: in the existing blocks /new while the waited-out first prompt starts a turn (v2 engine) case in apps/kimi-code/test/tui/kimi-tui-message-flow.test.ts, keep its deferred harness.createSession setup but submit through the actual editor instead of calling driver.handleUserInput('/new') directly:
driver.state.editor.setText('/new');
driver.state.editor.handleInput('\r');
expect(driver.state.editor.getText()).toBe('');
resolveCreate(lazySession);
await vi.waitFor(() => {
expect(lazySession.prompt).toHaveBeenCalledWith('hello', { promptId: undefined });
expect(stripSgr(renderTranscript(driver))).toContain('Cannot /new while streaming');
expect(driver.state.editor.getText()).toBe('/new'); // receives ''
});
The analogous /clear assertion also receives ''. These assertions exercise the submitted-input path that clears the editor; the existing direct-dispatch case does not check restoration.
What is the expected behavior?
Restore the rejected submitted command only if the editor is still empty and no replacement panel has opened. Preserve a newer user draft or an opened panel. The existing canRestoreSubmittedInput guard appears suitable.
Additional information
Executed the registered KimiTUI message-flow Vitest tests after building the workspace at f28c51c: /new and /clear restoration assertions failed; three controls passed (successful session replacement, newer editor draft, opened replacement panel). Five selected cases only; 359 others were filtered/unexecuted, not a full-suite pass. No production changes or real LLM calls.
Fresh source check: dispatch.ts, the existing message-flow test and CONTRIBUTING.md are unchanged at d4b9dc4. This is source continuity, not a new full-workspace test run.
Would you approve a small guarded input-restoration fix? I will wait for a maintainer /approve before opening a PR, as requested by CONTRIBUTING.
Contribution
- I am willing to submit a PR for this bug fix myself (please wait for maintainer approval in this issue first)
- 主要语言
- TypeScript
- 星标
- 7.8k
- 派生
- 1.3k
- 平均合并
- 1 天 7 小时
- 30 天内合并 PR
- 117
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
MoonshotAI/kimi-code 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 76/100
MoonshotAI/kimi-code#4177 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 70/100
MoonshotAI/kimi-code#4170 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 68/100
MoonshotAI/kimi-code#4147 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
MoonshotAI/kimi-code#4146 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
MoonshotAI/kimi-code#4141 ·
维护者通常 1 天内回复
查看 MoonshotAI/kimi-code 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 73/100
anomalyco/opencode#56380 · 1 条评论 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 72/100
-
BUG | `MCP 服务器` | 全局层行的停用/启用与删除报 404 server row not found，编辑保存会在 profile 层复制出重复行可能已有人在做 @w6242652 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 72/100
Chocobozzz/PeerTube#7832 ·
维护者通常 3 天内回复
-
Pay to use?未关闭
难度 1/5 1 小时以内 新手友好度 66/100
darkreader/darkreader#16108 · 1 条评论 ·
维护者通常 2 天内回复