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

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

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

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
rust
Ambito
backend

Direzione di ricerca

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.

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

Descrizione

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.

Lingua principale
Rust
Stelle
4k
Fork
654
Merge medio
4g 2h
PR unite (30g)
40

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.