Make TransportClosedException public and unify transport exception handling

[Copilot]

When a stdio server process exits during McpClient.CreateAsync (before completing the initialization handshake), callers cannot access StdioClientCompletionDetails (ExitCode, ProcessId, StandardErrorTail). The McpClient is created and disposed internally by CreateAsync, so Completion is never reachable. The only workaround is parsing IOException messages or reflecting on internal types.

Changes

• Make TransportClosedException public — was already internal with a comment saying "could be made public in the future." It extends IOException, so existing catch blocks are unaffected. Carries a Details property of type ClientCompletionDetails.

• Propagate channel completion exception to pending requests (McpSessionHandler.ProcessMessagesCoreAsync) — instead of always failing pending requests with a generic IOException("The server shut down unexpectedly."), propagate the TransportClosedException from the transport's channel completion when available.

• Throw TransportClosedException from CreateAsync when completion details add value — after initialization failure, check the session's completion details. Only throw TransportClosedException when the details carry an exception not already present in the original exception chain (reference equality walk). This gives stdio callers structured exit info while preserving existing HTTP exception behavior (e.g., HttpRequestException with StatusCode).

• Propagate caller-triggered OperationCanceledException in transports — when a caller's CancellationToken triggers an OperationCanceledException during a transport send or connect, re-throw it instead of wrapping it in IOException. Applied to StreamClientSessionTransport.SendMessageAsync, StreamServerTransport.SendMessageAsync, and SseClientSessionTransport.ConnectAsync. Also changed SseClientSessionTransport.ConnectAsync from throwing InvalidOperationException to IOException for consistency (connection failure is I/O, not invalid state).

Usage

try
{
    await using var client = await McpClient.CreateAsync(stdioTransport);
}
catch (TransportClosedException ex) when (ex.Details is StdioClientCompletionDetails stdio)
{
    // Structured access — no string parsing needed
    Console.WriteLine($"Exit code: {stdio.ExitCode}");   // e.g., 42 = Feature Disabled
    Console.WriteLine($"PID: {stdio.ProcessId}");
    Console.WriteLine($"Stderr: {string.Join("\n", stdio.StandardErrorTail ?? [])}");
}

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[halter73]

@copilot While not exactly the same thing, would it make sense to incorporate any of my fixes from https://github.com/modelcontextprotocol/csharp-sdk/tree/halter73/transport-exceptions into this PR? If it makes sense to just merge these changes into this PR, it'd definitely save me time, so I'd appreciate it 😆

[halter73]

@copilot To be clear, I'm not talking about anything more than the last two commits in https://github.com/modelcontextprotocol/csharp-sdk/tree/halter73/transport-exceptions. Ignore all the previous MRTR stuff

[Copilot]

@copilot While not exactly the same thing, would it make sense to incorporate any of my fixes from https://github.com/modelcontextprotocol/csharp-sdk/tree/halter73/transport-exceptions...

Incorporated the last two commits from halter73/transport-exceptions (fd2d71e, 19a1f2c) in 2a5e1d7:

• StreamClientSessionTransport.SendMessageAsync: re-throw OperationCanceledException when the caller's token triggers it
• StreamServerTransport.SendMessageAsync: same pattern
• SseClientSessionTransport.ConnectAsync: add OperationCanceledException guard + change InvalidOperationException to IOException