Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#4,225 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
60/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
cli

Hướng nghiên cứu

Bắt đầu tại apps/kimi-code/src/tui/commands/dispatch.ts quanh các dòng 383-399, nơi nhánh bận sau khi lắp ráp cho /new và /clear hiển thị lỗi rồi trả về mà không khôi phục đầu vào, và so sánh với guard canRestoreSubmittedInput hiện có. Chạy trường hợp blocks /new trong apps/kimi-code/test/tui/kimi-tui-message-flow.test.ts (engine v2) qua đường dẫn editor. Hoàn thành khi lệnh bị từ chối chỉ quay lại editor nếu editor vẫn trống và không có panel nào được mở, đồng thời các kiểm tra cho bản nháp mới hơn và panel đã mở vẫn đạt. Chờ maintainer /approve trước khi mở PR.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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)
Ngôn ngữ chính
TypeScript
Star
7.8k
Fork
1.3k
Merge trung bình
1 ngày 7 giờ
Pull request đã merge (30 ngày)
117

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của MoonshotAI/kimi-code

Tất cả issue của MoonshotAI/kimi-code

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.