Session not found handling

[tikal]

Bug description
After a server restart, a client calling the message endpoint with its session id it obtained via the previous running server instance gets a HTTP/1.1 500 Internal Server Error

Environment
java-sdk: 0.8.1 via Spring AI

Steps to reproduce
Call server message endpoint after a server restart, using previous sessionId

Expected behavior
Not too sure but it seems that the client should not interpret that there was indeed an internal server error because of a restart. It could either get a message which leads to recreating a session or there should be some sessions persistence between restart. There is a TODO around the code which returns the 500: https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-spring/mcp-spring-webflux/src/main/java/io/modelcontextprotocol/server/transport/WebFluxSseServerTransportProvider.java#L288

[tikal]

Actually the TODO is irrelevant here, the error occurs before and comes from a NullPointerException due to the null value coming out of the concurrent hash map get method: https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-spring/mcp-spring-webflux/src/main/java/io/modelcontextprotocol/server/transport/WebFluxSseServerTransportProvider.java#L281

[autoexebat]

Environment
Spring AI M8
Mcp SDK 0.9.0

I am currently using Spring AI where the MCP client and MCP server communicate via SSE. When the MCP server restarts, the SSE connection between the client and server is naturally broken.

The issue arises because the MCP client holds a session ID, but when the MCP server restarts, it doesn’t receive that session ID from the client — meaning the connection can’t be properly re-established.

At the moment, the only way I have found to resolve this is to also restart the MCP client so it can initiate a new SSE connection and synchronize the session ID with the server again.

I am wondering if there’s a better approach to handle this situation — ideally, allowing the client to detect the server restart and re-send the existing session ID, so the connection can resume without requiring a full client restart.

Any insights or suggestions on improving this behavior would be greatly appreciated.