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

Đang mở
  • Có gì không ổn?
#240 2 bình luận 0 reaction 1 người được giao Xem trên GitHub

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

@22chiragmodh đang làm issue này rồi.

Từ ngày 6/11/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
490
Fork
47
Merge trung bình
8 giờ 51 phút
Pull request đã merge (30 ngày)
91

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

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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 GoDiao/dreamcoder

Tất cả issue của GoDiao/dreamcoder

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.