TUI: rejected /new and /clear lose input after lazy session assembly

オープン 初心者向け
#4,225 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 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 の本文から書いたものです。

説明

bug
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?
  1. Start the TUI without an active session and submit a first prompt.
  2. While lazy session creation is pending, submit /new (or /clear).
  3. Let that session finish assembly and the first prompt start streaming.
  4. 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.

Source: https://github.com/MoonshotAI/kimi-code/blob/f28c51c01f025bba9f0d0f58f6309e7517a8cd02/apps/kimi-code/src/tui/commands/dispatch.ts#L383-L399

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

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

MoonshotAI/kimi-code のほかの issue

MoonshotAI/kimi-code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。