TUI: rejected /new and /clear lose input after lazy session assembly
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 60/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- cli
調査の方向性
apps/kimi-code/src/tui/commands/dispatch.ts の383〜399行目付近から始めてください。ここでは、/new と /clear の組み立て後のビジー分岐がエラーを表示し、入力を復元せずに戻ります。既存の canRestoreSubmittedInput ガードと比較してください。apps/kimi-code/test/tui/kimi-tui-message-flow.test.ts の blocks /new ケースを、エディタの経路を通して(v2 エンジン)実行してください。拒否されたコマンドは、エディタが空のままで、パネルが開いていない場合にのみエディタに戻り、より新しい下書きとパネルを開く制御が引き続き合格すれば完了です。PR を開く前に、メンテナーの /approve を待ってください。
索引モデルが 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
- スター
- 8k
- フォーク
- 1.3k
- 平均マージ
- 16時間 17分
- マージ済み PR(30日)
- 161
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
MoonshotAI/kimi-code のほかの issue
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
MoonshotAI/kimi-code#4591 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
MoonshotAI/kimi-code#4590 ·
メンテナーはふだん 1 日以内に返信
-
[Bug] Session Markdown export corrupts YAML frontmatter for workspace paths containing # or colon-space対応中かも @ADanMan が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
MoonshotAI/kimi-code#4588 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
ACP plan revision discards client feedback text対応中かも @markankamaransheogarat-sys が 1 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
MoonshotAI/kimi-code#4548 ·
メンテナーはふだん 1 日以内に返信
-
VS Code extension: clickable file links in chat drop the :line suffix, never jump to the line対応中かも @2SinceJuly が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
MoonshotAI/kimi-code#4398 ·
メンテナーはふだん 1 日以内に返信
MoonshotAI/kimi-code の issue をすべて見る
似ている issue
-
triage
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
🎙️ task - drop the raw `./node_modules/.bin/rhachet roles boot` line from bhuild's feedback templateオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
ehmpathy/rhachet-roles-bhuild#639 ·
メンテナーはふだん 1 日以内に返信
-
e2e-failure ready-to-code
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
redhat-developer/rhdh-plugin-export-overlays#4650 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 13 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
omdsh-dev/DSH-better-sidebar#1098 ·
メンテナーはふだん 2 日以内に返信