Fix http connector error handling #279
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Description
Changes
This PR enhance errors' explanations that were opaque when encountering http errors during connection. That was happening because SSE runs behind a TaskGroup, and the MCP doesn't handle the exceptions as in the streamable and doesn't convert them to McpError, so exceptions are propagated to our code through ExceptionGroup (due to async TaskGroup). Now we're retrieving the last exception (in theory in our case is always one) and making it explicit.
It were also removed all the checks for fallback, because when Streamable HTTP transport fails, it always raise an McpError that doesn't contain further information about why the error happened and the status code (only custom status codes of MCP) and then the fallback is always tried (it was always tried also before). That's because in the MCP, streamable error handling is different: if something is wrong a JSONRPCError is generated and in the ClientSession after some checks, an McpError is raised.
Someone could ask why SSE doesn't raise McpError and directly http or connections errors. That's because of the nature of SSE and how it's implemented on MCP. Errors are not handled in try blocks so when for example httpx raises an HTTPStatusError, it is propagated to our code.
Errors now
Testing
Backwards Compatibility
These changes are fully backwards compatible.
Related Issues
Fixes #278