modelcontextprotocol / modelcontextprotocol/csharp-sdk
stdio client never closes the server's stdin, so every client dispose burns the full ShutdownTimeout (5s by default)
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 4.5k
- Forks
- 814
- Avg merge
- 9d 19h
- Merged PRs (30d)
- 4
Description
Summary
StdioClientSessionTransport.CleanupAsync waits up to ShutdownTimeout for the server process to exit on its own, and only then kills the process tree. But nothing ever asks the server to exit: the client never closes the child's standard input, which the specification defines as the graceful-shutdown signal. So for any server that is alive and well behaved, that wait always runs to the full timeout — 5 seconds by default — and the process is force-killed afterwards regardless.
Hosts that create and dispose a client per tool call pay this on every single call.
Version checked: v1.4.0 (same code on main at the time of writing).
What the spec requires
From basic/transports/stdio — Shutdown:
- Closing the input stream to the child process (the server).
- Waiting for the server to exit.
- If the server does not exit within a reasonable time, forcibly terminating the process…
and:
Servers should exit promptly when their standard input is closed or reads return end-of-file […] the primary graceful-shutdown signal and the only portable one.
Step 1 is missing in the client.
What the SDK does
CleanupAsync order of operations:
WaitForProcessExitAsync()— bounded by_options.ShutdownTimeout- detach the stderr handler
StdioClientTransport.DisposeProcess(..., _options.ShutdownTimeout)
WaitForProcessExitAsync on .NET:
using var timeoutCts = new CancellationTokenSource(_options.ShutdownTimeout);
await _process.WaitForExitAsync(timeoutCts.Token).ConfigureAwait(false);
DisposeProcess:
processRunning = processRunning && !HasExited(process);
if (processRunning)
{
process.KillTree(shutdownTimeout);
}
There is no StandardInput.Close() / .Dispose() anywhere in StdioClientTransport.cs or StdioClientSessionTransport.cs. The default:
/// The amount of time to wait for the server to shut down gracefully. The default is 5 seconds.
public TimeSpan ShutdownTimeout { get; set; } = TimeSpan.FromSeconds(5);
The doc comment says "wait for the server to shut down gracefully" — but the server was never told to, so the wait is guaranteed to expire.
The server side already handles it
StreamServerTransport's read loop, same version:
if (line is null)
{
LogTransportEndOfStream(Name);
break;
}
EOF breaks the loop, SetDisconnected completes the transport, the process exits. So closing stdin would make servers built on this SDK exit in milliseconds — the fix needs no change on the server side.
Impact
Measured on a host that creates and disposes a stdio client per tool call: 6.7–7.0s wall clock per tool call, of which ~5s is this wait. One of the measured calls was a query that returned an empty array — no data, no work — and still took 6.95s. Eighteen tool cycles across four configurations, all in the same band.
Two consequences, not one:
- Latency: a fixed ~5s added to every client dispose.
- The server is always force-killed. Because the wait can only expire,
KillTreealways runs, so the server never executes its own shutdown path — no flush, no cleanup, no chance to release resources. LoweringShutdownTimeoutas a workaround makes the kill arrive sooner, so it trades latency for a harder kill rather than fixing it.
Suggested fix
Close the child's standard input at the start of CleanupAsync, before WaitForProcessExitAsync. The subsequent wait then ends when the server actually exits, usually in milliseconds, and KillTree degrades to the safety net the spec intends. Optionally escalate SIGTERM before SIGKILL on POSIX, as the spec describes.
Repro
Start any stdio server built on this SDK, issue one tool call, dispose the client, and time the dispose. It returns after ShutdownTimeout, independently of what the server does. Setting ShutdownTimeout to a small value makes the dispose proportionally faster, which confirms the wait is the whole cost.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in StdioClientSessionTransport.CleanupAsync and compare the process-handling code in StdioClientTransport.cs and StdioClientSessionTransport.cs with StreamServerTransport's EOF handling. Reproduce by disposing a stdio client and timing it with the default ShutdownTimeout. Done means stdin is closed before waiting, the server exits promptly, and KillTree remains only as a fallback.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 84/100