fix:avoid streamable listening sse duplicate creation #524
Conversation
|
Are you working for TaoBao Group? |
| String lastId = request.headers().asHttpHeaders().getFirst(HttpHeaders.LAST_EVENT_ID); | ||
| return ServerResponse.ok() | ||
| .contentType(MediaType.TEXT_EVENT_STREAM) | ||
| .body(session.replay(lastId), ServerSentEvent.class); | ||
| } | ||
| if (listenedStream instanceof McpStreamableServerSessionStream) { | ||
| logger.debug("Listening stream for session: {} exists.", sessionId); |
There was a problem hiding this comment.
if(logger.isDebugEnabled) ...
|
Hey, thanks for the proposal. I see this might be an issue, agreed. However, my worry is that someone might be making a new GET request because the previous one is broken. The way forward that I see is not to reject the new GET request but instead make sure that if one listening stream exists it is properly closed and replaced with this new one instead. WDYT? |
…o make way for the new listening SSE stream
Thanks for the helpful suggestion—code updated, tested, and confirmed working. |
.../java/io/modelcontextprotocol/server/transport/WebFluxStreamableServerTransportProvider.java
Outdated
Show resolved
Hide resolved
.../java/io/modelcontextprotocol/server/transport/WebFluxStreamableServerTransportProvider.java
Outdated
Show resolved
Hide resolved
mcp/src/main/java/io/modelcontextprotocol/spec/McpStreamableServerSession.java
Outdated
Show resolved
Hide resolved
I will continue to follow up and solve this problem.🤝 |
Motivation and Context
In the streamable context, repeated GET requests within the same session spawn multiple listening SSE connections, which
can lead the server to create unnecessary SSE
How Has This Been Tested?
Breaking Changes
Types of changes
Checklist
Additional context