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());
	}

[osenx]

I think we can combine two ways. First, expand the ping type, and then use the error handler to support any errors

[chengyi3192]

Hi @ tzolov, ping is not an event, but a comment in the sse protocol that starts with ":". The official handling method is: it should be ignored.
However, the buildEvent method in org.springframework.cttp.codec.ServerSetEventHttpMessage Reader intercepts the content after ":" and puts it in the comment, but the event in ServerSentEvent is empty, which can cause an exception to be thrown.

I think PR should be merged immediately because sending ping messages is present in many frameworks.

event-stream-interpretation

exception

[tzolov]

@chengyi3192 thanks for clarifying the semantics of the comment SSE (non)events.

[tzolov]

@goecho I guess we can strengthen the check to verify that the id, event and data fields are empty as well? And perhaps generalize to isCommentLine

[goecho]

@tzolov Great point — I've now added the checks for id, event, and data, and pulled the logic into an isCommentLine() helper. Thanks!