Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,338 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@talhayme ci sta già lavorando.

Dal 12/10/2026.

  • #1344 di @talhayme — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
api, backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).

Lingua principale
Rust
Stelle
4k
Fork
662
Merge medio
3g 20h
PR unite (30g)
30

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/rust-sdk

Tutte le issue di modelcontextprotocol/rust-sdk

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.