Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Fermée
  • Quelque chose ne va pas ?
#1,338 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

@talhayme y travaille déjà.

Depuis le 12/10/2026.

  • #1344 par @talhayme — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
rust
Domaine
api, backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Rust
Étoiles
4.1k
Forks
680
Merge moyen
3 j 20 h
PR mergées (30 j)
32

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelcontextprotocol/rust-sdk

Toutes les issues de modelcontextprotocol/rust-sdk

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.