Inbox cancel returns 204 even when nothing was withdrawn
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 78/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
Hướng nghiên cứu
Kiểm tra packages/server/src/handlers/session.ts, đặc biệt là session.inbox.cancel và trình xử lý cùng cấp session.inbox.update, sau đó tìm các bài kiểm thử tương ứng của trình xử lý hộp thư đến phiên. Tái hiện việc hủy sau khi một mục đã được chuyển giao và xác minh rằng việc rút lại thực sự vẫn có thể phân biệt với xung đột. Công việc hoàn tất khi hành vi của phản hồi khớp với hợp đồng API đã chọn và các bài kiểm thử liên quan bao phủ cả hai trường hợp.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Description
What happens. In v2.0.32, DELETE /api/session/:sessionID/inbox/:inboxID answers 204 No Content in two different situations:
- the pending item was withdrawn, so it will never reach the model;
- the item was no longer pending, for example because it had already been delivered to the session.
The handler catches the conflict and returns the same empty success (packages/server/src/handlers/session.ts, lines 551–559 at v2.0.32):
.handle(
"session.inbox.cancel",
Effect.fn(function* (ctx) {
yield* session.cancelInbox({ sessionID: ctx.params.sessionID, inboxID: ctx.params.inboxID }).pipe(
Effect.catchTag("Session.NotFoundError", missingSession),
Effect.catchTag("Session.InboxConflictError", () => Effect.void),
)
return HttpApiSchema.NoContent.make()
}),
)
The sibling session.inbox.update handler (line 564) sends the same InboxConflictError through pendingMutation, which answers 409 Conflict. Only cancel hides it.
Why it matters. A client that offers "undo my queued message" wants to put the withdrawn text back in the input box. Between the client's inbox read and the cancel, the running turn can end and the item can be delivered. The cancel still returns 204. If the client then restores the text, the person may send the same request again, although the first copy already ran. The client cannot tell the two cases apart:
- the item is absent from a fresh inbox read in both cases;
- the transcript proves delivery only when the message is in the page the client reads.
Request. Let the cancel response say what happened. For example:
- answer 409 Conflict for an item that is no longer pending, as
session.inbox.updatealready does, and keep 204 for a real withdrawal; or - if changing the status would break existing callers, return a small body such as
{ "withdrawn": true }or{ "withdrawn": false }.
Either form lets a client restore the text only after a real withdrawal, and otherwise point the person to the delivered message.
Plugins
None
OpenCode version
2.0.32
Steps to reproduce
- Start a reply that takes a few seconds.
- While it runs, queue a follow-up message. It appears in
GET /api/session/:sessionID/inbox. - Wait until the reply ends and the follow-up appears in
GET /api/session/:sessionID/message. - Send
DELETE /api/session/:sessionID/inbox/:inboxIDfor that follow-up. The answer is 204, the same as for a real withdrawal.
- Ngôn ngữ chính
- TypeScript
- Star
- 215k
- Fork
- 28.9k
- Merge trung bình
- 11 giờ 19 phút
- Pull request đã merge (30 ngày)
- 320
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của anomalyco/opencode
-
pending close triaging
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
anomalyco/opencode#57209 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
reproduced
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
anomalyco/opencode#57127 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
pending close triaging
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
anomalyco/opencode#57070 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Plan mode leave reminder becomes the final user turn after a tool-driven agent switch, models refuseCó thể đã có người làm @Veld101 đã nhận 1 ngày trước. Đang mởreproduced
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
anomalyco/opencode#57013 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
anomalyco/opencode#56891 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của anomalyco/opencode
Issue tương tự
-
area:editor bug issue-form:bug P0 platform:windows review: low
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
1lck/Lithe-IDEA#1388 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
fix(api): isToolAuditEnabled swallows database read errors on auditToolOperations without loggingĐang mởarea: backend bug priority: low
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
snapotter-hq/SnapOtter#3238 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
rig up --plan times out after 5 s and reports an UNKNOWN outcome while the daemon completes the planĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
filesystem: search_files does not expand non-wildcard excludePatterns like directory_tree doesĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
modelcontextprotocol/servers#5216 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày