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

Abierto
  • ¿Algo no está bien?
#240 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@22chiragmodh ya está trabajando en esto.

Desde el 6/11/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
490
Forks
47
Merge medio
8 h 51 min
PR fusionados (30 d)
91

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de GoDiao/dreamcoder

Todos los issues de GoDiao/dreamcoder

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.