feat:HttpClientSseClientTransport sendMessage throw McpError when status is not success #383
+5
−2
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.
Motivation and Context
When sendMessage encounters abnormal HTTP status codes like 404 from the server, the MCP client can only wait until the client-side timeout occurs. Moreover, the client always receives a generic Timeout exception, which isn't helpful—especially when troubleshooting issues.
To improve this, we could return an MCPError instead, including the HTTP status code in the data field. This would give clients more flexibility to handle different status codes with appropriate fallback logic. For example, if the server intercepts invalid MCP requests and returns specific status codes, the client could use this information to take proper action instead of just seeing a timeout error, which often leaves users confused about how to proceed.
How Has This Been Tested?
Tested by use case.
Breaking Changes
Types of changes
Checklist
Additional context