Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,338 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

@talhayme ya está trabajando en esto.

Desde el 12/10/2026.

  • #1344 de @talhayme — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
api, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Rust
Estrellas
4k
Forks
662
Merge medio
3 d 7 h
PR fusionados (30 d)
37

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/rust-sdk

Todos los issues de modelcontextprotocol/rust-sdk

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.