Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Client: an abandoned call_tool sends no notifications/cancelled — the MRTR helper hides each round's RequestHandle

Đang mở
  • Có gì không ổn?
#1,338 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 3 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
48/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
api, backend

Hướng nghiên cứu

Start by reading RunningService::call_tool, call_tool_with_mrtr_max_rounds, and peer.call_tool_once to trace how each round's RequestHandle is managed. The issue identifies three possible approaches; assess how cancellation interacts with retries and input_required handling. Done means an abandoned or cancelled call sends notifications/cancelled for its in-flight round.

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

Mô tả

enhancement P2 ready for work T-service

rmcp 3.5.0, client side. A caller that abandons a tools/call — its own deadline passed, say — has no way to tell the server, because the MRTR helper hides the request it is waiting on.

RunningService::call_tool (via call_tool_with_mrtr_max_rounds) drives each round with peer.call_tool_once → send_request, which awaits a RequestHandle internally. So:

  • Dropping the call_tool future sends nothing. RequestHandle has no Drop behaviour; send_timeout_cancel_notification runs only when the handle's own PeerRequestOptions timeout fires. A wrapper like tokio::time::timeout(bound, service.call_tool(params)) abandons the request locally while the server keeps working on it, and its response stream stays open until the server answers or the socket's idle timeout fires.
  • A caller can't drive the rounds itself either. send_cancellable_request / send_request_with_option return a RequestHandle with cancel(), but answering an input_required round needs prepare_input_required_retry, which is private. Re-implementing it means re-implementing the elicitation hand-off to the local ClientHandler.

A call_tool that can be cancelled through any of these would do:

  1. A drop guard in the MRTR driver that holds the current round's RequestHandle and sends notifications/cancelled for it when the future is dropped mid-round (the cheapest; it covers every timeout/select! caller).
  2. An option on call_tool for a total deadline or a CancellationToken, which sends notifications/cancelled for the round in flight when it fires (the spirit of PeerRequestOptions::max_total_timeout, across rounds).
  3. prepare_input_required_retry made public, so callers can drive rounds with send_cancellable_request.

(1) seems the most useful, since abandoning a future is how most async callers bound a call.

Context: agentd bounds every tool call it makes on behalf of a workflow step or a model turn. Today an abandoned call is documented as "not cancelled" because of this (crates/mcp/src/rmcp_client.rs, call_tool).

Ngôn ngữ chính
Rust
Star
4k
Fork
654
Merge trung bình
3 ngày 4 giờ
Pull request đã merge (30 ngày)
37

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 modelcontextprotocol/rust-sdk

Tất cả issue của modelcontextprotocol/rust-sdk

Issue tương tự

Thêm issue về Rust

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.