Fix: Handle SSE ping messages in WebFluxSseClientTransport

[goecho]

• Add check for SSE ping messages from fastMCP server
• Log debug message when ping received instead of throwing exception
• Complete the stream on ping events
• Matches behavior of Python SDK which treats pings as keep-alive

Motivation and Context

How Has This Been Tested?

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

[tzolov]

Hi @goecho , can you please elaborate on this. I'm not able to find ping event type mentioned by the specification?

[goecho]

Hi @tzolov this behavior is not defined in the MCP protocol itself—it's specific to the Python implementation using the fastmcp library. The behavior comes from the keep-alive mechanism in its dependency, the sse-starlette library. You can refer to the code here: https://github.com/sysid/sse-starlette/blob/main/sse_starlette/sse.py#L214

[YunKuiLu]

Hi @tzolov @goecho , I had the same issue and opened PR #223 to dealt with it by adding an sseErrorHandler parameter.
The SSE comment message : ping isn't part of the MCP spec, so I'm thinking of just logging it as a warning by default. How does that sound?

[goecho]

Hi @YunKuiLu ,I don't think this is a good idea — we shouldn't change the original logic. The original approach was better: throwing an exception for unknown types helps expose issues, which is better than just logging them.

[YunKuiLu]

@goecho Thank you for your reply.

I actually considered both options: throwing an exception to stop the client or just logging it. But since the issue is only logged in HttpClientSseClientTransport, I think the client should keep the same default behavior for consistency.

java-sdk/mcp/src/main/java/io/modelcontextprotocol/client/transport/HttpClientSseClientTransport.java

Lines 363 to 365 in d9006ec

	else {
	logger.error("Received unrecognized SSE event type: {}", event.type());
	}