modelcontextprotocol / modelcontextprotocol/rust-sdk

Should ServiceExt::serve() return after initialization?

Open
#1,143 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

needs repro P3 question T-service
Dominant language
Rust
Stars
3.9k
Forks
645
Avg merge
4d 13h
Merged PRs (30d)
36

Description

Looking at examples/servers/src/counter_stdio.rs (but other examples and README.md use the same code):

let service = Counter::new().serve(stdio()).await.inspect_err(|e| {
    tracing::error!("serving error: {:?}", e);
})?;

service.waiting().await?;

The above code implies to me that ServiceExt::serve() returns either a RunningService or an initialization error after being awaited.
After the successful initialization I expect that I can do other stuff and then eventually wait for the service to shut down (e.g. via the second line).

However, any code I add after the first line is never reached.
So I think something is wrong here.

Either I'm misunderstanding the API and ServiceExt::serve() is not supposed to return after initialization.
But then I wonder why we even have the second line in the example and how I'm supposed to do other (asynchronous) stuff after starting the service.

Or this is a bug and ServiceExt::serve() is supposed to return after initialization.

Thank you for your help!
I'm really impressed by this package and glad it sees so much development!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with examples/servers/src/counter_stdio.rs and compare its ServiceExt::serve() call with the subsequent service.waiting().await?; README.md contains the same pattern. Then trace the serve and waiting entry points to determine when control returns and what completion behavior the example promises. Done means the behavior and example usage agree, with the relevant scenario covered by an appropriate test if one exists.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.