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

Aperta
  • Qualcosa non va?
#240 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@22chiragmodh ci sta già lavorando.

Dal 6/11/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
TypeScript
Stelle
490
Fork
47
Merge medio
8h 51m
PR unite (30g)
91

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di GoDiao/dreamcoder

Tutte le issue di GoDiao/dreamcoder

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.