| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
…seAsync
When SseClientSessionTransport.ConnectAsync fails (e.g. server returns 405),
the catch block calls CloseAsync() before wrapping the error in
InvalidOperationException. However, CloseAsync() awaits the already-faulted
_receiveTask without a try-catch, causing the original HttpRequestException
to propagate out of CloseAsync and preempt the InvalidOperationException
wrapping. Callers then receive a bare HttpRequestException instead of the
documented InvalidOperationException("Failed to connect transport", ex).
The fix wraps `await _receiveTask` in CloseAsync with a try-catch to
swallow already-observed exceptions from the faulted task.
Code references:
SseClientSessionTransport.ConnectAsync (catch block calls CloseAsync):
https://github.com/modelcontextprotocol/csharp-sdk/blob/v0.9.0-preview.2/src/ModelContextProtocol.Core/Client/SseClientSessionTransport.cs#L52-L67
SseClientSessionTransport.CloseAsync (awaits _receiveTask without try-catch):
https://github.com/modelcontextprotocol/csharp-sdk/blob/v0.9.0-preview.2/src/ModelContextProtocol.Core/Client/SseClientSessionTransport.cs#L108-L130
Testing:
# Build all frameworks (only netstandard2.0 fails — pre-existing on main):
dotnet build tests/ModelContextProtocol.Tests/ '/p:NoWarn=NU1903%3BMCPEXP001'
# Run full transport suite (74 tests × 3 frameworks = 222 total, 0 failures):
dotnet test tests/ModelContextProtocol.Tests/ '/p:NoWarn=NU1903%3BMCPEXP001' --no-build --filter "FullyQualifiedName~Transport" --framework net10.0
dotnet test tests/ModelContextProtocol.Tests/ '/p:NoWarn=NU1903%3BMCPEXP001' --no-build --filter "FullyQualifiedName~Transport" --framework net9.0
dotnet test tests/ModelContextProtocol.Tests/ '/p:NoWarn=NU1903%3BMCPEXP001' --no-build --filter "FullyQualifiedName~Transport" --framework net8.0
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Not exactly related to this PR, but I can't unsee the incorrect InvalidOperationException we throw from line 65. Can we turn that into just a throw; while we're at it? |
Sorry, something went wrong.
…-exception-swallow # Conflicts: # tests/ModelContextProtocol.Tests/Transport/HttpClientTransportAutoDetectTests.cs
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
This will be a subtle breaking change because of changing the exception types thrown. We'll capture it in the release notes. Thanks for getting this PR started, @xue-cai. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
When SseClientSessionTransport.ConnectAsync fails (for example, an SSE GET returns 405), ReceiveMessagesAsync reports the failure through _connectionEstablished and the connection path closes the transport.
Previously, ReceiveMessagesAsync rethrew after reporting that failure. This faulted _receiveTask, so CloseAsync could rethrow the same exception while awaiting it and preempt the original connection-failure path.
The fix leaves the receive task completed after recording and logging the failure, allowing CloseAsync to await it normally. ConnectAsync then rethrows the original exception after cleanup rather than adding an inaccurate wrapper.
The regression coverage verifies direct SSE failures preserve their original exception, and that auto-detection preserves the initial Streamable HTTP error while retaining the SSE fallback failure as its inner exception.