MoonshotAI / MoonshotAI/kimi-code
[VSCode] Busy-session rejection is reported as "Internal error occurred." instead of the busy message
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 7.5k
- Forks
- 1.2k
- Avg merge
- 11h 53m
- Merged PRs (30d)
- 350
Description
Bug description
In the VSCode extension, any prompt sent while a session is busy is rejected by SessionRuntime.runTurnAction/beginHostAction with a plain Error("A response is already being generated for this session.") (apps/vscode/src/runtime/session-runtime.ts). emitError maps any non-KimiError to code "internal", and getUserMessage("internal", detail) in apps/vscode/shared/errors.ts prefers its static table entry over the real message — so the webview shows "Internal error occurred." for what is actually just "session busy".
The error table already has the right message for this case: turn.agent_busy → "A message is being sent. Please wait." — it is simply never used on this path.
Reproduction
- Open any Kimi Code chat in VSCode and send a message that starts a long-running turn.
- While the turn is running, send another message.
- The chat shows "Internal error occurred."
A wedged turn (see #1050) makes this much worse: the session stays busy forever, so every subsequent message shows "Internal error occurred." with no hint about the real state.
Expected behavior
The rejection surfaces as code turn.agent_busy with the message "A message is being sent. Please wait." (with the original detail attached), not a generic internal error.
Suggested fix
Throw new KimiError("turn.agent_busy", ALREADY_GENERATING_MESSAGE) instead of new Error(...) at the two rejection sites in apps/vscode/src/runtime/session-runtime.ts. emitError already special-cases KimiError and the error table already maps the code; only the throw site needs to change (plus test expectations in apps/vscode/test/kimi-runtime.test.ts / settings-store.test.ts).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in apps/vscode/src/runtime/session-runtime.ts at the two busy-session rejection sites, then inspect emitError and the error table in apps/vscode/shared/errors.ts. Run the relevant cases in apps/vscode/test/kimi-runtime.test.ts and settings-store.test.ts. Done means a busy prompt surfaces code turn.agent_busy and the message “A message is being sent. Please wait.” rather than the generic internal error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript, vscode
- Domain
- desktop, developer-experience, tooling
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100