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

ProgressDispatcher: a slow progress subscriber blocks subscribe() and delivery for other tokens

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

Los mantenedores suelen responder en 3 días

@monody0007 ya está trabajando en esto.

Desde el 29/9/2026.

  • #1310 de @monody0007 — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
rust
Área
backend

Línea de trabajo

Start in crates/rmcp/src/handler/client/progress.rs and review PR #1310, which contains the proposed fix and tests. Run test_slow_subscriber_does_not_block_other_tokens, test_resubscribing_a_dropped_token_keeps_the_new_subscriber, test_dropping_a_replaced_subscriber_keeps_its_replacement, and dropping_a_subscriber_unregisters_it_without_a_runtime; done means all pass without changing the public API.

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

Descripción

bug P1 ready for work T-handler

Describe the bug

ProgressDispatcher::handle_notification (crates/rmcp/src/handler/client/progress.rs) holds the read guard of its tokio::sync::RwLock across sender.send(notification).await. When one subscriber's channel is full (capacity 16), that send waits while the guard is held. Tokio's RwLock is write-preferring, so a concurrent subscribe() then waits for the write lock, and every later notification for other tokens queues behind it. One slow consumer stalls progress notifications for all in-flight requests until it catches up or is dropped.

Two smaller problems in the same file:

  • ProgressSubscriber::drop removes its entry with tokio::spawn, so dropping a subscriber outside a Tokio runtime panics (there is no reactor running).
  • Because that removal is deferred, dropping a subscriber and subscribing again with the same token can remove the new subscription, and the new stream then receives no notifications.

To Reproduce

PR #1310 adds tests for all three: test_slow_subscriber_does_not_block_other_tokens, test_resubscribing_a_dropped_token_keeps_the_new_subscriber, test_dropping_a_replaced_subscriber_keeps_its_replacement and the unit test dropping_a_subscriber_unregisters_it_without_a_runtime. By the PR's own runs they fail on main and pass with the change.

Expected behavior

A slow subscriber only delays its own token, and dropping or replacing a subscriber never affects another subscription.

Additional context

The fix in #1310 holds a std::sync::RwLock only to look up, insert or remove an entry and releases it before sending; Drop removes only its own entry, synchronously. The public API does not change. If you would rather keep the async lock and only shorten the critical section, I can rework it that way.

Disclosure: an AI agent (Claude, via Claude Code) that I run found the problem, wrote the fix and tests in #1310, and wrote and posted this issue.

Lenguaje dominante
Rust
Estrellas
4k
Forks
654
Merge medio
3 d 16 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.