Agents: send the queue version so queued-message edits can be ordered against queue_update

Abierto
  • ¿Algo no está bien?
#31,652 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
28/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, react, typescript
Área
backend, frontend

Línea de trabajo

Start in coderd/x/chatd/stream_loop.go, where chat.QueueVersion is compared before queue_update is emitted, and trace the PATCH handler for /api/v2/chats/{chat}/queue/{id}, which returns no body. On the client, read runEditQueuedMessage in site/src/pages/AgentsPage/components/ChatConversation/chatQueueReconciliation.ts. Done when the version is carried on the stream event, the PATCH response and ChatMessagesResponse, and the client skips its local editing_since write unless the PATCH version is newer than the last applied one.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

When two clients have the same chat open, the client can show a stale "under edit" marker on a queued message. For example, tab A begins editing a queued row while tab B saves it and ends the edit. If B's queue_update reaches tab A before A's PATCH resolves, runEditQueuedMessage (site/src/pages/AgentsPage/components/ChatConversation/chatQueueReconciliation.ts, added in #29555) still writes A's editing_since marker over the newer queue. No later queue_update repairs it, so tab A shows the wrong row-under-edit state until the next queue change or a reload.

A client-only fix is not safe, because the client cannot order a queue_update against its own PATCH. An update that arrives during the request can come from before the edit (for example, the server promoting another row, which one tab can trigger) or from after it (another tab ending the edit). In both cases the row arrives unmarked. #31651 tried two client-side guards, and each one opened a new race in the single-tab path:

  • Skipping the local write when a queue update arrived during the request drops a successful begin. The composer then loses its target and demotes typed text to a new-message draft.
  • Refetching the queue instead shares the chatQueueConvergence query, so the refetch can join a GET that started before the PATCH. It also keeps a queued save's promise pending after its mutation settled, so text typed during the refetch can be overwritten. An older update that arrives during the refetch also discards it.

The server already tracks chat.QueueVersion and compares it before it emits queue_update (coderd/x/chatd/stream_loop.go), but it does not send the version to the client. Proposed fix:

  1. Add the queue version to the queue_update stream event and to ChatMessagesResponse.
  2. Return it from PATCH /api/v2/chats/{chat}/queue/{id}, which today returns no body.
  3. In the client store, record the last applied queue version, and have runEditQueuedMessage write its local marker only when the PATCH's version is newer.

That one comparison removes the stale marker and the races above without a refetch.

Refs #31651

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

Lenguaje dominante
Go
Estrellas
17.3k
Forks
1.6k
Merge medio
3 d 13 h
PR fusionados (30 d)
604

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 coder/coder

Todos los issues de coder/coder

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.