Composer shows a disabled send button instead of Stop while the CLI is starting

オープン
  • 何か問題がありますか？
#240 コメント 2 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@22chiragmodh がすでに取り組んでいます。

2026年11月6日 から。

評価

この issue はまだ評価されていません。

説明

bug good first issue

Problem

When a message has to start the session's CLI first (the first message of a session, a session whose CLI stopped, a repository launch that creates a worktree), the composer shows a grayed-out send button for a few seconds instead of the stop button. During that time the user cannot stop the turn, and the "Creating worktree" status is not shown either.

Found by reading the code on main (b4ee8b36). Please reproduce it first; the quickest way is a new session in a git project with "new worktree" on, where startup takes longest.

Cause

  1. On send, the desktop sets chatState: 'thinking' optimistically and clears the composer (chatStore.ts). The stop button shows.
  2. The server's deliverUserTurn awaits ensureCliSessionStarted (handler.ts). When the CLI is not running this takes seconds.
  3. Startup changes session state (process phase, workspace, worktree status), and each change is pushed to clients as a session_patch.
  4. On every patch the desktop recomputes chatState from the server's state (chatStore.ts). turn.phase is still idle, so chatState goes back to idle: send button, disabled because the composer is empty.
  5. Only after the CLI started and the message was sent does the server apply turn_started (handler.ts), and the stop button comes back.

Session state is owned by the server, so the server must say "a turn is under way" for the whole window. The fix is not a client-side guard against the mirror.

Proposed design

1. A new turn phase starting. SessionState.turn.phase becomes 'idle' | 'starting' | 'running' | 'awaiting_permission': the message was accepted and the server is waiting for the CLI. Add a reducer event (e.g. turn_starting { at }). turn_started and the CLI's session_state_changed: running move it to running and keep its startedAt, so the elapsed time counts from the send.

2. Decide "own turn or queue" when the message is accepted. Today deliverUserTurn checks turnQueue.shouldQueue after the CLI started. With starting counted as "not idle", the message that started the turn would queue behind itself. Move the decision before any await (after the /clear handling):

  • queue path: as today (wait for the CLI, then send with priority later);
  • own turn: apply turn_starting, then wait for runtime transitions and CLI startup, then send and apply turn_started.

A second message sent while the first one is still starting takes the queue path. It must reach the CLI after the first message.

3. Process startup must not wipe the starting turn. applyProcessPhase resets turn to idle when the process phase becomes starting, stopped or failed (reducer.ts). Keep a starting turn through the process's starting phase. Still reset it on stopped and failed.

4. Every way out of the startup window ends the turn. Startup failure, CLI_RESTART_FAILED after a runtime transition, and CLI_NOT_RUNNING when sending must all leave the turn idle. Otherwise the client is stuck on the stop button. Use one exit path in deliverUserTurn, not a turn_ended copied into each branch.

5. Stop during startup. Make it behave like Stop right after a message reaches a running CLI: the message stays in the conversation, and the turn is interrupted. The server records the stop and ends the turn at once. When the CLI is up, it sends the message and interrupts immediately. Expect one pitfall: the CLI then reports running before it reports the interrupted result, which would bring the stop button back for a moment. The pipeline's existing stopRequested handling is where to deal with that. Don't kill the starting process.

6. Desktop and H5. Treat starting as busy (chatStateFromMirror → thinking, isTurnRunning, StreamingIndicator). Show the existing "Creating worktree" status during startup. Update the SessionState type on both sides. H5 uses the same frontend.

Check the other readers of turn.phase. Most already test !== 'idle', so starting counts as busy automatically. Confirm each one is right:

  • handler.ts: artifact turn tracking, restart deferral (deferRestartUntilTurnEnds), the runtime check;
  • sessionLinksService.ts: whether the parent is running (for reports), the running flag in ListSessions;
  • turnQueueService.ts;
  • browserHost/runtime.ts;
  • the reducer.

Acceptance

  • From the moment the message is sent until the turn ends, the composer shows the stop button. No idle frame appears in between, on the desktop or on H5.
  • A second client and a client that reconnects during startup both see the turn as under way.
  • A CLI startup failure leaves the session idle and shows the error.
  • Stop during startup leaves the session idle, without the stop button flashing back. The message stays in history.
  • Two messages sent during startup arrive in order: the first starts a turn and the second is queued.
  • Messages from other sessions (origin set) that start a stopped CLI behave the same way.
  • Tests:
    • server: reducer (turn_starting, process starting keeps it, stopped/failed clear it), deliverUserTurn (state during startup, failure, Stop during startup, second message during startup);
    • desktop: a patch that arrives during startup keeps the stop button.
  • Check both themes if the status text changes. Add a CHANGELOG entry under Fixed.

Relevant docs: session state design (turn state section) and session links design (queued messages). Update the session state doc with the new phase.

主要言語
TypeScript
スター
490
フォーク
47
平均マージ
8時間 51分
マージ済み PR（30日）
91

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

GoDiao/dreamcoder のほかの issue

GoDiao/dreamcoder の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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