401 Unauthorized: Session not found

[JMLX42]

Following up on a bug tracked on the rmcp-actix-web crate:

https://gitlab.com/lx-industries/rmcp-actix-web/-/issues/15#note_2699030396

This bug also affects the offficial axum implementation. So I'm creating this issue to make sure we agree on the expected behavior.

Describe the bug

The session is automatically destroyed when the SSE streaming connection ends in the HTTP streamable implementation.

1. Session Creation: Client POSTs → Session ID returned ✅
2. SSE Connection: Client GETs SSE stream ✅
3. Service Task: Spawned task calls service.waiting().await
4. Critical Issue: When SSE connection drops, service.waiting() completes
5. Auto Cleanup: Session gets automatically destroyed 💥
6. Failure: Next request with same session ID → 401: Session not found

To Reproduce
Steps to reproduce the behavior:

1. run the composition_streamable_http_example example
2. open MCP inspector
3. call "List Tools" twice or call List Tools then the sum tool

Expected behavior

Calling "List Tools" twice or calling multiple tools should work.

Logs

Not available yet. Will add ASAP.

Additional context

stateful_mode = false solves the problem. But many (most?) tools - such as sum - are stateful.

[JMLX42]

As a reference, from the TypeScript implementation, here's how sessions are managed:

TypeScript SDK Session Management

Main StreamableHttp Implementation:

https://github.com/modelcontextprotocol/typescript-sdk/blob/main/src/server/streamableHttp.ts

1. SSE Connection Close Handler

  res.on("close", () => {
    this._streamMapping.delete(streamId);  // Only removes stream, NOT session
  });

Link: https://github.com/modelcontextprotocol/typescript-sdk/blob/1f5950be01927cb8e4e555cb5584c44db1604f39/src/server/streamableHttp.ts#L519-521

2. Session Close Method

  async close(): Promise<void> {
    // Close all SSE connections
    this._streamMapping.forEach((response) => {
      response.end();
    });
    this._streamMapping.clear();
    this._requestResponseMap.clear();
    this.onclose?.();
  }

Link: https://github.com/modelcontextprotocol/typescript-sdk/blob/1f5950be01927cb8e4e555cb5584c44db1604f39/src/server/streamableHttp.ts#L643-653

3. DELETE Request Handler

  async handleDeleteRequest(): Promise<void> {
    await Promise.resolve(this._onsessionclosed?.(this.sessionId!));
    await this.close();  // Only destroys session on explicit DELETE
  }

Link: https://github.com/modelcontextprotocol/typescript-sdk/blob/1f5950be01927cb8e4e555cb5584c44db1604f39/src/server/streamableHttp.ts#L548-558

Our Rust Implementation (The Problem)

Current Broken Code:

  let _ = session_manager
      .close_session(&session_id)  // ← Automatic cleanup (WRONG)
      .await

The Evidence

The TypeScript SDK clearly shows:

• Connection close → Only remove stream mapping
• Session destruction → Only via explicit DELETE request
• No automatic session cleanup when SSE connections end

Key Finding: When an SSE connection closes, the TypeScript SDK only removes that specific stream from tracking - it does NOT destroy the session.

Comparison with Our Rust Implementation

TypeScript (Correct):

• SSE disconnect → Remove stream mapping only
• Session persists → Can accept new connections
• Session destroyed → Only via DELETE request

Our Rust (Currently Broken):

• SSE disconnect → service.waiting() completes → Destroy entire session ❌
• Session gone → Subsequent requests fail

Our Fix (Aligns with TypeScript):

• SSE disconnect → Remove stream only
• Session persists → Can accept new connections ✅
• Session destroyed → Only via DELETE request ✅

Proposed fix

Follow the pattern used by the Typescript SDK for session management.
Sessions should survive the SSE connection in the HTTP Streamable implementation.

1. remove the session cleanup here
2. Explicit cleanup still works via DELETE requests

[4t145]

I think It's not because of we close the session here. Of cousre we need to close the session after transport terminated, the transport represent a session here.

SSE disconnect → service.waiting() completes → Destroy entire session

service.waiting() completes → Destroy entire session is correct.

SSE disconnect → service.waiting() complete is not supposed to happen.

The problem is that when sse connection is closed. the worker service get an error while trying to send a message from rmcp service to sse stream, and return this error to rmcp service. Then rmcp service see it as an error of transport it self, then wrongly close the entire service.

So, when session get an error when sending message through sse stream, it shouldn't take it as a transport error. Session should keep this message and wait for reconnection. From rmcp server service's perspective, the message is still on the way. And only after the session expired, rmcp server service can finally get a transport error and quit.

update

Just checked the code, I didn't find out why SSE disconnect would cause service quit, and I will do some test on this.

update

Just tested with @modelcontextprotocol/inspector, it looks like sse stream closing won't cause transport terminate. （So I cannot reproduce this）

[JMLX42]

The error was misdiagnosed on my side: https://gitlab.com/lx-industries/rmcp-actix-web/-/issues/15#note_2700956235

I check the examples in this repo with the axum implementation and they don't suffer from the same inconsistency.

Still, I think there might be an inconsistency with how the TypeScript SDK handles the sessions termination vs how rmcp does it. But maybe the TypeScript SDK is not doing the right thing.

[4t145]

Still, I think there might be an inconsistency with how the TypeScript SDK handles the sessions termination vs how rmcp does it.

Yes we do have some inconsistency with TypeScript SDK, I think it's because ts sdk doesn't trying to manage things like task cancellation, so it can be much easier to implement.

[JMLX42]

Still, I think there might be an inconsistency with how the TypeScript SDK handles the sessions termination vs how rmcp does it.

Yes we do have some inconsistency with TypeScript SDK, I think it's because ts sdk doesn't trying to manage things like task cancellation, so it can be much easier to implement.

Meaning the Rust SDK is actually more in the right and we can close this issue?