Everything Server crashes when multiple clients reconnect

[chemicL]

Describe the bug
The new everything server exits with an error when a client (or multiple) quickly disconnects and connects again.
We are unable to utilize the latests version from a recent rewrite in the java-sdk integration tests due to this issue.

To Reproduce
Steps to reproduce the behavior:

1. Launch the everything server (either with sse or streamableHttp transports)
2. Launch inspector
3. Connect
4. Hit the Reconnect button multiple times quickly
5. Observe the everything server crash

Expected behavior
The server should support reconnects and multiple clients.

Logs

Server logs

» npx -y @modelcontextprotocol/server-everything streamableHttp
Starting Streamable HTTP server...
MCP Streamable HTTP Server listening on port 3001
Received MCP POST request
Session initialized with ID: d664c339-8b71-40e5-b73c-0da840435532
Received MCP POST request
Received MCP GET request
Establishing new SSE stream for session d664c339-8b71-40e5-b73c-0da840435532
Received MCP POST request


Received session termination request for session d664c339-8b71-40e5-b73c-0da840435532
Transport closed for session d664c339-8b71-40e5-b73c-0da840435532, removing from transports map
Received MCP POST request
Session initialized with ID: 90ca21c0-ccc7-4724-8a57-606370044ddb
Received MCP POST request
Received MCP GET request
Establishing new SSE stream for session 90ca21c0-ccc7-4724-8a57-606370044ddb
Received MCP POST request
Received session termination request for session 90ca21c0-ccc7-4724-8a57-606370044ddb
Transport closed for session 90ca21c0-ccc7-4724-8a57-606370044ddb, removing from transports map
Received MCP POST request
Session initialized with ID: 0f7a84e6-93a7-42de-8848-680b4a51338b
Received MCP POST request
Received MCP GET request
Establishing new SSE stream for session 0f7a84e6-93a7-42de-8848-680b4a51338b
Received session termination request for session 0f7a84e6-93a7-42de-8848-680b4a51338b
Transport closed for session 0f7a84e6-93a7-42de-8848-680b4a51338b, removing from transports map
Received MCP POST request
Session initialized with ID: 4d188707-873e-4f60-be6f-1a6be24b0870
Received MCP POST request
Received MCP GET request
Establishing new SSE stream for session 4d188707-873e-4f60-be6f-1a6be24b0870
file:///Users/jdariusz/.npm/_npx/5b2dd62b9d0bddd4/node_modules/@modelcontextprotocol/sdk/dist/esm/shared/protocol.js:770
            throw new Error('Not connected');
                  ^

Error: Not connected
    at Server.notification (file:///Users/jdariusz/.npm/_npx/5b2dd62b9d0bddd4/node_modules/@modelcontextprotocol/sdk/dist/esm/shared/protocol.js:770:19)
    at Server.sendLoggingMessage (file:///Users/jdariusz/.npm/_npx/5b2dd62b9d0bddd4/node_modules/@modelcontextprotocol/sdk/dist/esm/server/index.js:418:29)
    at McpServer.sendLoggingMessage (file:///Users/jdariusz/.npm/_npx/5b2dd62b9d0bddd4/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:751:28)
    at requestRoots (file:///Users/jdariusz/.npm/_npx/5b2dd62b9d0bddd4/node_modules/@modelcontextprotocol/server-everything/dist/server/roots.js:51:30)
    at async syncRoots (file:///Users/jdariusz/.npm/_npx/5b2dd62b9d0bddd4/node_modules/@modelcontextprotocol/server-everything/dist/server/roots.js:64:13)

Node.js v22.7.0

Inspector logs

🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀
New StreamableHttp connection request
Query parameters: {"url":"http://localhost:3001/mcp","transportType":"streamable-http"}
Created StreamableHttp server transport
Created StreamableHttp client transport
Client <-> Proxy  sessionId: 8ce1bf8c-ce07-4793-a1be-fbbbd27d134e
Proxy  <-> Server sessionId: d664c339-8b71-40e5-b73c-0da840435532
Received POST message for sessionId 8ce1bf8c-ce07-4793-a1be-fbbbd27d134e
Received GET message for sessionId 8ce1bf8c-ce07-4793-a1be-fbbbd27d134e
Received POST message for sessionId 8ce1bf8c-ce07-4793-a1be-fbbbd27d134e
Received DELETE message for sessionId 8ce1bf8c-ce07-4793-a1be-fbbbd27d134e
Transports removed for sessionId 8ce1bf8c-ce07-4793-a1be-fbbbd27d134e
New StreamableHttp connection request
Query parameters: {"url":"http://localhost:3001/mcp","transportType":"streamable-http"}
Created StreamableHttp server transport
Created StreamableHttp client transport
Client <-> Proxy  sessionId: 0bf711da-6b32-4f1e-95ed-03e2d449fdb0
Proxy  <-> Server sessionId: 90ca21c0-ccc7-4724-8a57-606370044ddb
Received POST message for sessionId 0bf711da-6b32-4f1e-95ed-03e2d449fdb0
Received GET message for sessionId 0bf711da-6b32-4f1e-95ed-03e2d449fdb0
Received POST message for sessionId 0bf711da-6b32-4f1e-95ed-03e2d449fdb0
Received DELETE message for sessionId 0bf711da-6b32-4f1e-95ed-03e2d449fdb0
New StreamableHttp connection request
Query parameters: {"url":"http://localhost:3001/mcp","transportType":"streamable-http"}
Created StreamableHttp server transport
Created StreamableHttp client transport
Client <-> Proxy  sessionId: 7ce41e18-9fbc-4b9f-9301-31c33ea257dd
Transports removed for sessionId 0bf711da-6b32-4f1e-95ed-03e2d449fdb0
Proxy  <-> Server sessionId: 0f7a84e6-93a7-42de-8848-680b4a51338b
Received POST message for sessionId 7ce41e18-9fbc-4b9f-9301-31c33ea257dd
Received GET message for sessionId 7ce41e18-9fbc-4b9f-9301-31c33ea257dd
Received DELETE message for sessionId 7ce41e18-9fbc-4b9f-9301-31c33ea257dd
Transports removed for sessionId 7ce41e18-9fbc-4b9f-9301-31c33ea257dd
New StreamableHttp connection request
Query parameters: {"url":"http://localhost:3001/mcp","transportType":"streamable-http"}
Created StreamableHttp server transport
Created StreamableHttp client transport
Client <-> Proxy  sessionId: fd0d8aaa-59ae-455f-b7dd-b01f5b8382cb
Proxy  <-> Server sessionId: 4d188707-873e-4f60-be6f-1a6be24b0870
Received POST message for sessionId fd0d8aaa-59ae-455f-b7dd-b01f5b8382cb
Received GET message for sessionId fd0d8aaa-59ae-455f-b7dd-b01f5b8382cb
Received DELETE message for sessionId fd0d8aaa-59ae-455f-b7dd-b01f5b8382cb
Error from MCP server: TypeError: fetch failed
    at node:internal/deps/undici/undici:13179:13
    at async StreamableHTTPClientTransport.terminateSession (file:///Users/jdariusz/development/github/modelcontextprotocol/inspector/node_modules/@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:355:30)
    at async file:///Users/jdariusz/development/github/modelcontextprotocol/inspector/node_modules/@modelcontextprotocol/inspector/server/build/index.js:261:17 {
  [cause]: Error: read ECONNRESET
      at TCP.onStreamRead (node:internal/stream_base_commons:218:20) {
    errno: -54,
    code: 'ECONNRESET',
    syscall: 'read'
  }
}
Error in /mcp route: TypeError: fetch failed
    at node:internal/deps/undici/undici:13179:13
    at async StreamableHTTPClientTransport.terminateSession (file:///Users/jdariusz/development/github/modelcontextprotocol/inspector/node_modules/@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:355:30)
    at async file:///Users/jdariusz/development/github/modelcontextprotocol/inspector/node_modules/@modelcontextprotocol/inspector/server/build/index.js:261:17 {
  [cause]: Error: read ECONNRESET
      at TCP.onStreamRead (node:internal/stream_base_commons:218:20) {
    errno: -54,
    code: 'ECONNRESET',
    syscall: 'read'
  }
}
Error from MCP server: Error: SSE stream disconnected: TypeError: terminated
    at processStream (file:///Users/jdariusz/development/github/modelcontextprotocol/inspector/node_modules/@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:203:88)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
New StreamableHttp connection request
Query parameters: {"url":"http://localhost:3001/mcp","transportType":"streamable-http"}
Created StreamableHttp server transport
Created StreamableHttp client transport
Client <-> Proxy  sessionId: 3846c0f5-da61-43f1-aadb-baec84e67907
Connection refused. Is the MCP server running?

Additional context
We have temporarily pinned to the previous working version (https://www.npmjs.com/package/@modelcontextprotocol/server-everything/v/2025.12.18).

A side note also: the change in tool names and the different number of resources are backwards incompatible changes, but we should be ok unless more significant changes are yet to be discovered. For now the biggest issue is the server crashing. Thanks in advance for taking a look.

[olaservo]

@claude curious what your take is on this issue, wrt the latest everything server exiting with an error when a client (or multiple) quickly disconnects and connects again?

[claude]

Claude finished @olaservo's task in 1m 49s —— View job

---

Analysis of Everything Server Crash Issue

I've analyzed the crash and identified the root cause. Here's my technical take on the issue:

Tasks

• Read repository guidelines (CLAUDE.md)
• Examine everything server source code
• Analyze the requestRoots/syncRoots functions
• Understand session lifecycle management
• Identify root cause of "Not connected" error
• Provide technical analysis and recommendations

---

Root Cause

The crash occurs due to a race condition between session cleanup and asynchronous operations. Here's what happens:

1. Session Initialization (src/everything/server/index.ts:92-101):

   • When a client connects, oninitialized callback is triggered
   • syncRoots() is called with a 350ms delay via setTimeout(() => syncRoots(server, sessionId), 350)
   • This delay is intentional to ensure the notifications/initialized handler completes first

2. Rapid Reconnection Scenario:

   • Client connects → session initialized → syncRoots() scheduled for 350ms later
   • Client disconnects quickly (before 350ms) → transport closes → session cleaned up
   • 350ms timer fires → syncRoots() executes on a now-disconnected session
   • requestRoots() tries to send a logging message via sendLoggingMessage() at src/everything/server/roots.ts:47
   • SDK's notification() method checks if (!this._transport) at protocol.js:769-770
   • Throws Error: Not connected because the transport was already removed

3. Why the Previous Version Worked:

   • The previous version (2025.12.18) likely had different session lifecycle management
   • The recent rewrite (PR New everything server #3121) introduced the setTimeout pattern which creates this vulnerability

The Problem in Detail

Looking at src/everything/transports/streamableHttp.ts:84-93, the cleanup flow is:

server.server.onclose = async () => {
  const sid = transport.sessionId;
  if (sid && transports.has(sid)) {
    console.log(`Transport closed for session ${sid}, removing from transports map`);
    transports.delete(sid);
    cleanup(sid);
  }
};

However, the setTimeout in src/everything/server/index.ts:101 is not canceled when the session closes, so it continues to execute even after the transport is gone.

Impact

• Affects both sse and streamableHttp transports
• Crashes the entire server process, not just the specific session
• Makes the server unusable for scenarios requiring quick reconnections (integration tests, unstable connections, inspector reconnect button)
• This is a backwards-incompatible regression from the working 2025.12.18 version

Recommended Solutions

Option 1: Cancel the timer on session close (Cleanest)

• Store the timeout handle when calling setTimeout
• Clear it in the cleanup function
• Prevents the delayed syncRoots() from executing on closed sessions

Option 2: Guard against disconnected state

• Wrap sendLoggingMessage() calls in try-catch blocks
• Check transport state before attempting to send notifications
• More defensive but doesn't address the root cause

Option 3: Check connection state before sync

• Add a connection check at the start of syncRoots() and requestRoots()
• Return early if transport is not available
• Simple but doesn't prevent unnecessary work

My recommendation: Option 1 is the cleanest solution. The timeout handle should be stored and canceled during cleanup to prevent the race condition entirely.

Additional Observations

From src/everything/server/roots.ts:31-95, I notice:

• The function already has error handling (try-catch at lines 65-76)
• However, the error is caught and logged via sendLoggingMessage() which itself throws when disconnected
• This creates a double-fault scenario where error handling triggers the actual crash

The error handling at lines 66-75 tries to log the error but fails with the same "Not connected" error, which is unhandled and crashes the process.

---

Would you like me to implement a fix for this issue?

[cliffhall]

A fix is in #3242