Skip to content

feat:HttpClientSseClientTransport sendMessage throw McpError when status is not success #383

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

taobaorun
Copy link

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.

 listTools error io.modelcontextprotocol.spec.McpError: The server returned a 404 status code
	at io.modelcontextprotocol.client.transport.HttpClientSseClientTransport.lambda$sendMessage$0(HttpClientSseClientTransport.java:430)
	Suppressed: The stacktrace has been enhanced by Reactor, refer to additional information below: 
Assembly trace from producer [reactor.core.publisher.MonoCompletionStage] :
	reactor.core.publisher.Mono.fromFuture(Mono.java:629)
	io.modelcontextprotocol.client.transport.HttpClientSseClientTransport.sendMessage(HttpClientSseClientTransport.java:424)


Breaking Changes

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

@taobaorun taobaorun changed the title Feature/feature sendmessage return mcperror feat:HttpClientSseClientTransport sendMessage throw McpError when status is not success Jul 10, 2025
@taobaorun
Copy link
Author

taobaorun commented Jul 11, 2025

@tzolov please review this pr to see if it's reasonable.thanks.

sink.error(new RuntimeException( "Sending message failed with a non-OK HTTP code: " + response.statusCode()));

-->

sink.error(new McpError(new JSONRPCError(ErrorCodes.INVALID_REQUEST, "Sending message failed with a non-OK HTTP code: " + response.statusCode(), response.statusCode())));

I saw that the code submitted on June 13 has returned RuntimeException. Can it be returned as McpError, and the status code is returned as data so that the client can get its value? I want to change RuntimeException to McpError. Is it also suitable for the scenario?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant