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

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

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

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
28/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, react, typescript
Lĩnh vực
backend, frontend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Go
Star
17.3k
Fork
1.6k
Merge trung bình
3 ngày 13 giờ
Pull request đã merge (30 ngày)
604

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

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

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

Tất cả issue của coder/coder

Issue tương tự

Thêm issue về Go

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.