Skip to content

Streamable HTTP: Multiple SSE streams cause infinite reconnect loop #659

Closed
Closed
Streamable HTTP: Multiple SSE streams cause infinite reconnect loop#659

Description

@its-mash
its-mash
opened on Feb 14, 2026

Summary

When multiple SSE streams exist for the same session (e.g. from POST response reconnections), LocalSessionWorker::resume() unconditionally replaces self.common.tx, killing the other stream's receiver. Both EventSource connections then reconnect every sse_retry seconds, leapfrogging each other in an infinite loop that floods the server with GET requests.

Affected versions: rmcp 0.14.0, 0.15.0
Severity: Critical — causes infinite reconnect loops with clients like Cursor, and breaks server-to-client notifications over Streamable HTTP

Root Cause

The MCP Streamable HTTP transport sends POST SSE responses with a priming event containing retry: 3000. When the POST stream ends (after delivering the response), the browser's EventSource API automatically reconnects via GET. This creates multiple competing EventSource connections:

  1. The initial standalone GET stream (primary notification channel)
  2. Reconnecting GETs from completed POST responses (initialize, tools/list, etc.)

Each reconnecting GET calls resume() which unconditionally replaces self.common.tx:

// Before fix — local.rs resume()None => {let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);self.common.tx = tx;// ← Unconditionally replaces sender, kills other stream// ...}

Dropping the old sender closes the old receiver, terminating the OTHER EventSource's stream. That stream then reconnects, replacing the sender again. Both leapfrog every sse_retry (3s) indefinitely.

The Leapfrog Loop

1. Client POST initialize → SSE response with priming (retry: 3000) → stream ends
2. Client GET (standalone) → becomes primary common channel (tx1/rx1)
3. POST EventSource reconnects via GET (3s later) → replaces common.tx → kills rx1
4. GET from step 2 reconnects → replaces common.tx → kills stream from step 3
5. Repeat every 3 seconds indefinitely

Server logs confirm the pattern — alternating GET requests every 3 seconds with different Last-Event-ID values:

13:33:51.670 GET Last-Event-ID: 0/2 ← from completed POST response
13:33:54.668 GET Last-Event-ID: 0 ← from killed standalone stream
13:33:57.679 GET Last-Event-ID: 0/2 ← leapfrog
13:34:00.674 GET Last-Event-ID: 0 ← leapfrog
...

Additional Issue: Cache Replay Loop

Even without the leapfrog, resume() called sync() on the common channel to replay cached events. Replaying server-initiated list_changed notifications caused clients to re-process old signals, triggering unnecessary re-fetches every reconnection cycle.

What Happens in Practice

Cursor (infinite loop)

  • Connects via POST initialize + GET standalone
  • POST SSE stream ends → EventSource reconnects via GET
  • Two competing streams leapfrog every 3 seconds
  • Server flooded with GET requests indefinitely
  • Notifications intermittently lost as channels are swapped

VS Code (silent notification loss)

  • Reconnects SSE every ~5 minutes with same session ID
  • Each reconnection replaces the channel sender
  • Previous stream's receiver is orphaned
  • notify_tool_list_changed().await returns Ok(()) — silent failure

Fix: Shadow Channels

PR: #660

Instead of unconditionally replacing the common channel, check if the primary is still active:

  • Primary dead (tx.is_closed()) → Replace it. New stream becomes primary.
  • Primary alive → Create a shadow stream — an idle SSE connection kept alive by SSE keep-alive pings that does NOT receive notifications and does NOT replace the primary channel.
fnresume_or_shadow_common(&mutself) -> Result<StreamableHttpMessageReceiver,SessionError>{let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);ifself.common.tx.is_closed(){// Primary is dead — replace itself.common.tx = tx;}else{// Primary is alive — create shadow (idle, keep-alive only)self.shadow_txs.push(tx);}Ok(StreamableHttpMessageReceiver{http_request_id:None,inner: rx })}

Why Not 409 Conflict?

The initial approach (matching the TypeScript SDK) was to return 409 Conflict on duplicate standalone streams. However:

  1. The MCP spec states: "The client MAY remain connected to multiple SSE streams simultaneously" — 409 is not spec-compliant
  2. 409 causes Cursor to fail entirely on reconnection (500 errors from unhandled Conflict)
  3. The reconnecting EventSources are legitimate HTTP requests — they need a valid stream back

Shadow channels are the correct approach: keep all connections alive without interference.

Why No Cache Replay on Common Channel?

Common channel notifications (tools/list_changed, resources/list_changed) are idempotent signals. Replaying cached ones causes clients to re-process old events, triggering unnecessary re-fetches or infinite notification loops. Missing one is harmless — the next real event arrives naturally. Request-wise channels still use sync() for proper response replay.

Changes (5 commits)

CommitDescription
8bd424eInitial 409 Conflict approach (returned error on duplicate standalone stream)
0d03eb5Handle resume with completed request-wise channels (fall through to common)
a7bb822Remove 409 Conflict — allow channel replacement per MCP spec
7cf5406Skip cache replay (sync) when replacing active streams
a7df58cShadow channels — the final fix that prevents the leapfrog loop

Files Changed

  • crates/rmcp/src/transport/streamable_http_server/session/local.rs
    • Added shadow_txs: Vec<Sender<ServerSseMessage>> to LocalSessionWorker
    • New method resume_or_shadow_common() with primary-alive check
    • Updated resume() to use shadow logic for both direct common and request-wise fallback paths
    • Removed sync() calls on common channel resume
    • Updated close_sse_stream() to clear shadow senders
    • Updated create_local_session() to initialize shadow_txs

Test Results

  • Cursor connects and initializes successfully (no 409/500 errors)
  • Cursor does NOT enter infinite GET reconnect loop after connection
  • Feature changes trigger exactly one batch of list_changed notifications
  • Cursor receives and processes notifications correctly (re-fetches tools/resources)
  • No notification replay loop (no repeated ResourceListChanged every 3s)
  • VS Code connects and works correctly (unaffected by changes)
  • cargo check --workspace passes

Environment

  • rmcp 0.15.0 (also affects 0.14.0)
  • StreamableHttpService with stateful_mode: true
  • LocalSessionManager (default session manager)
  • Clients tested: Cursor 2.4.37, VS Code MCP Extension

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
       blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Streamable HTTP: Multiple SSE streams cause infinite reconnect loop · Issue #659 · modelcontextprotocol/rust-sdk · GitHub
      Skip to content
      Streamable HTTP: Multiple SSE streams cause infinite reconnect loop #659
      Closed
      Closed
      Streamable HTTP: Multiple SSE streams cause infinite reconnect loop#659
      Description
      @its-mash
      its-mash
      opened on Feb 14, 2026
      Summary
      When multiple SSE streams exist for the same session (e.g. from POST response reconnections), LocalSessionWorker::resume() unconditionally replaces self.common.tx, killing the other stream's receiver. Both EventSource connections then reconnect every sse_retry seconds, leapfrogging each other in an infinite loop that floods the server with GET requests.
      Affected versions: rmcp 0.14.0, 0.15.0
      Severity: Critical — causes infinite reconnect loops with clients like Cursor, and breaks server-to-client notifications over Streamable HTTP
      Root Cause
      The MCP Streamable HTTP transport sends POST SSE responses with a priming event containing retry: 3000. When the POST stream ends (after delivering the response), the browser's EventSource API automatically reconnects via GET. This creates multiple competing EventSource connections:
      1. The initial standalone GET stream (primary notification channel)
      2. Reconnecting GETs from completed POST responses (initialize, tools/list, etc.)
      Each reconnecting GET calls resume() which unconditionally replaces self.common.tx:
      // Before fix — local.rs resume()None => {let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);self.common.tx = tx;// ← Unconditionally replaces sender, kills other stream// ...}
      Dropping the old sender closes the old receiver, terminating the OTHER EventSource's stream. That stream then reconnects, replacing the sender again. Both leapfrog every sse_retry (3s) indefinitely.
      The Leapfrog Loop
      1. Client POST initialize → SSE response with priming (retry: 3000) → stream ends
2. Client GET (standalone) → becomes primary common channel (tx1/rx1)
3. POST EventSource reconnects via GET (3s later) → replaces common.tx → kills rx1
4. GET from step 2 reconnects → replaces common.tx → kills stream from step 3
5. Repeat every 3 seconds indefinitely

      Server logs confirm the pattern — alternating GET requests every 3 seconds with different Last-Event-ID values:
      13:33:51.670 GET Last-Event-ID: 0/2 ← from completed POST response
13:33:54.668 GET Last-Event-ID: 0 ← from killed standalone stream
13:33:57.679 GET Last-Event-ID: 0/2 ← leapfrog
13:34:00.674 GET Last-Event-ID: 0 ← leapfrog
...

      Additional Issue: Cache Replay Loop
      Even without the leapfrog, resume() called sync() on the common channel to replay cached events. Replaying server-initiated list_changed notifications caused clients to re-process old signals, triggering unnecessary re-fetches every reconnection cycle.
      What Happens in Practice
      Cursor (infinite loop)
      • Connects via POST initialize + GET standalone
      • POST SSE stream ends → EventSource reconnects via GET
      • Two competing streams leapfrog every 3 seconds
      • Server flooded with GET requests indefinitely
      • Notifications intermittently lost as channels are swapped
      VS Code (silent notification loss)
      • Reconnects SSE every ~5 minutes with same session ID
      • Each reconnection replaces the channel sender
      • Previous stream's receiver is orphaned
      • notify_tool_list_changed().await returns Ok(()) — silent failure
      Fix: Shadow Channels
      PR: #660
      Instead of unconditionally replacing the common channel, check if the primary is still active:
      • Primary dead (tx.is_closed()) → Replace it. New stream becomes primary.
      • Primary alive → Create a shadow stream — an idle SSE connection kept alive by SSE keep-alive pings that does NOT receive notifications and does NOT replace the primary channel.
      fnresume_or_shadow_common(&mutself) -> Result<StreamableHttpMessageReceiver,SessionError>{let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);ifself.common.tx.is_closed(){// Primary is dead — replace itself.common.tx = tx;}else{// Primary is alive — create shadow (idle, keep-alive only)self.shadow_txs.push(tx);}Ok(StreamableHttpMessageReceiver{http_request_id:None,inner: rx })}
      Why Not 409 Conflict?
      The initial approach (matching the TypeScript SDK) was to return 409 Conflict on duplicate standalone streams. However:
      1. The MCP spec states: "The client MAY remain connected to multiple SSE streams simultaneously" — 409 is not spec-compliant
      2. 409 causes Cursor to fail entirely on reconnection (500 errors from unhandled Conflict)
      3. The reconnecting EventSources are legitimate HTTP requests — they need a valid stream back
      Shadow channels are the correct approach: keep all connections alive without interference.
      Why No Cache Replay on Common Channel?
      Common channel notifications (tools/list_changed, resources/list_changed) are idempotent signals. Replaying cached ones causes clients to re-process old events, triggering unnecessary re-fetches or infinite notification loops. Missing one is harmless — the next real event arrives naturally. Request-wise channels still use sync() for proper response replay.
      Changes (5 commits)
      CommitDescription
      8bd424eInitial 409 Conflict approach (returned error on duplicate standalone stream)
      0d03eb5Handle resume with completed request-wise channels (fall through to common)
      a7bb822Remove 409 Conflict — allow channel replacement per MCP spec
      7cf5406Skip cache replay (sync) when replacing active streams
      a7df58cShadow channels — the final fix that prevents the leapfrog loop
      Files Changed
      • crates/rmcp/src/transport/streamable_http_server/session/local.rs
        • Added shadow_txs: Vec<Sender<ServerSseMessage>> to LocalSessionWorker
        • New method resume_or_shadow_common() with primary-alive check
        • Updated resume() to use shadow logic for both direct common and request-wise fallback paths
        • Removed sync() calls on common channel resume
        • Updated close_sse_stream() to clear shadow senders
        • Updated create_local_session() to initialize shadow_txs
      Test Results
      •  Cursor connects and initializes successfully (no 409/500 errors)
      •  Cursor does NOT enter infinite GET reconnect loop after connection
      •  Feature changes trigger exactly one batch of list_changed notifications
      •  Cursor receives and processes notifications correctly (re-fetches tools/resources)
      •  No notification replay loop (no repeated ResourceListChanged every 3s)
      •  VS Code connects and works correctly (unaffected by changes)
      • cargo check --workspace passes
      Environment
      • rmcp 0.15.0 (also affects 0.14.0)
      • StreamableHttpService with stateful_mode: true
      • LocalSessionManager (default session manager)
      • Clients tested: Cursor 2.4.37, VS Code MCP Extension
      Metadata
      Metadata
      Assignees
      No one assigned
        Labels
        No labels
        No labels
        Type
        No type
        Projects
        No projects
          Milestone
          No milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Streamable HTTP: Multiple SSE streams cause infinite reconnect loop · Issue #659 · modelcontextprotocol/rust-sdk · GitHub
          Skip to content
          Streamable HTTP: Multiple SSE streams cause infinite reconnect loop #659
          Closed
          Closed
          Streamable HTTP: Multiple SSE streams cause infinite reconnect loop#659
          Description
          @its-mash
          its-mash
          opened on Feb 14, 2026
          Summary
          When multiple SSE streams exist for the same session (e.g. from POST response reconnections), LocalSessionWorker::resume() unconditionally replaces self.common.tx, killing the other stream's receiver. Both EventSource connections then reconnect every sse_retry seconds, leapfrogging each other in an infinite loop that floods the server with GET requests.
          Affected versions: rmcp 0.14.0, 0.15.0
          Severity: Critical — causes infinite reconnect loops with clients like Cursor, and breaks server-to-client notifications over Streamable HTTP
          Root Cause
          The MCP Streamable HTTP transport sends POST SSE responses with a priming event containing retry: 3000. When the POST stream ends (after delivering the response), the browser's EventSource API automatically reconnects via GET. This creates multiple competing EventSource connections:
          1. The initial standalone GET stream (primary notification channel)
          2. Reconnecting GETs from completed POST responses (initialize, tools/list, etc.)
          Each reconnecting GET calls resume() which unconditionally replaces self.common.tx:
          // Before fix — local.rs resume()None => {let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);self.common.tx = tx;// ← Unconditionally replaces sender, kills other stream// ...}
          Dropping the old sender closes the old receiver, terminating the OTHER EventSource's stream. That stream then reconnects, replacing the sender again. Both leapfrog every sse_retry (3s) indefinitely.
          The Leapfrog Loop
          1. Client POST initialize → SSE response with priming (retry: 3000) → stream ends
2. Client GET (standalone) → becomes primary common channel (tx1/rx1)
3. POST EventSource reconnects via GET (3s later) → replaces common.tx → kills rx1
4. GET from step 2 reconnects → replaces common.tx → kills stream from step 3
5. Repeat every 3 seconds indefinitely

          Server logs confirm the pattern — alternating GET requests every 3 seconds with different Last-Event-ID values:
          13:33:51.670 GET Last-Event-ID: 0/2 ← from completed POST response
13:33:54.668 GET Last-Event-ID: 0 ← from killed standalone stream
13:33:57.679 GET Last-Event-ID: 0/2 ← leapfrog
13:34:00.674 GET Last-Event-ID: 0 ← leapfrog
...

          Additional Issue: Cache Replay Loop
          Even without the leapfrog, resume() called sync() on the common channel to replay cached events. Replaying server-initiated list_changed notifications caused clients to re-process old signals, triggering unnecessary re-fetches every reconnection cycle.
          What Happens in Practice
          Cursor (infinite loop)
          • Connects via POST initialize + GET standalone
          • POST SSE stream ends → EventSource reconnects via GET
          • Two competing streams leapfrog every 3 seconds
          • Server flooded with GET requests indefinitely
          • Notifications intermittently lost as channels are swapped
          VS Code (silent notification loss)
          • Reconnects SSE every ~5 minutes with same session ID
          • Each reconnection replaces the channel sender
          • Previous stream's receiver is orphaned
          • notify_tool_list_changed().await returns Ok(()) — silent failure
          Fix: Shadow Channels
          PR: #660
          Instead of unconditionally replacing the common channel, check if the primary is still active:
          • Primary dead (tx.is_closed()) → Replace it. New stream becomes primary.
          • Primary alive → Create a shadow stream — an idle SSE connection kept alive by SSE keep-alive pings that does NOT receive notifications and does NOT replace the primary channel.
          fnresume_or_shadow_common(&mutself) -> Result<StreamableHttpMessageReceiver,SessionError>{let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);ifself.common.tx.is_closed(){// Primary is dead — replace itself.common.tx = tx;}else{// Primary is alive — create shadow (idle, keep-alive only)self.shadow_txs.push(tx);}Ok(StreamableHttpMessageReceiver{http_request_id:None,inner: rx })}
          Why Not 409 Conflict?
          The initial approach (matching the TypeScript SDK) was to return 409 Conflict on duplicate standalone streams. However:
          1. The MCP spec states: "The client MAY remain connected to multiple SSE streams simultaneously" — 409 is not spec-compliant
          2. 409 causes Cursor to fail entirely on reconnection (500 errors from unhandled Conflict)
          3. The reconnecting EventSources are legitimate HTTP requests — they need a valid stream back
          Shadow channels are the correct approach: keep all connections alive without interference.
          Why No Cache Replay on Common Channel?
          Common channel notifications (tools/list_changed, resources/list_changed) are idempotent signals. Replaying cached ones causes clients to re-process old events, triggering unnecessary re-fetches or infinite notification loops. Missing one is harmless — the next real event arrives naturally. Request-wise channels still use sync() for proper response replay.
          Changes (5 commits)
          CommitDescription
          8bd424eInitial 409 Conflict approach (returned error on duplicate standalone stream)
          0d03eb5Handle resume with completed request-wise channels (fall through to common)
          a7bb822Remove 409 Conflict — allow channel replacement per MCP spec
          7cf5406Skip cache replay (sync) when replacing active streams
          a7df58cShadow channels — the final fix that prevents the leapfrog loop
          Files Changed
          • crates/rmcp/src/transport/streamable_http_server/session/local.rs
            • Added shadow_txs: Vec<Sender<ServerSseMessage>> to LocalSessionWorker
            • New method resume_or_shadow_common() with primary-alive check
            • Updated resume() to use shadow logic for both direct common and request-wise fallback paths
            • Removed sync() calls on common channel resume
            • Updated close_sse_stream() to clear shadow senders
            • Updated create_local_session() to initialize shadow_txs
          Test Results
          •  Cursor connects and initializes successfully (no 409/500 errors)
          •  Cursor does NOT enter infinite GET reconnect loop after connection
          •  Feature changes trigger exactly one batch of list_changed notifications
          •  Cursor receives and processes notifications correctly (re-fetches tools/resources)
          •  No notification replay loop (no repeated ResourceListChanged every 3s)
          •  VS Code connects and works correctly (unaffected by changes)
          • cargo check --workspace passes
          Environment
          • rmcp 0.15.0 (also affects 0.14.0)
          • StreamableHttpService with stateful_mode: true
          • LocalSessionManager (default session manager)
          • Clients tested: Cursor 2.4.37, VS Code MCP Extension
          Metadata
          Metadata
          Assignees
          No one assigned
            Labels
            No labels
            No labels
            Type
            No type
            Projects
            No projects
              Milestone
              No milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Streamable HTTP: Multiple SSE streams cause infinite reconnect loop · Issue #659 · modelcontextprotocol/rust-sdk · GitHub
              Skip to content
              Streamable HTTP: Multiple SSE streams cause infinite reconnect loop #659
              Closed
              Closed
              Streamable HTTP: Multiple SSE streams cause infinite reconnect loop#659
              Description
              @its-mash
              its-mash
              opened on Feb 14, 2026
              Summary
              When multiple SSE streams exist for the same session (e.g. from POST response reconnections), LocalSessionWorker::resume() unconditionally replaces self.common.tx, killing the other stream's receiver. Both EventSource connections then reconnect every sse_retry seconds, leapfrogging each other in an infinite loop that floods the server with GET requests.
              Affected versions: rmcp 0.14.0, 0.15.0
              Severity: Critical — causes infinite reconnect loops with clients like Cursor, and breaks server-to-client notifications over Streamable HTTP
              Root Cause
              The MCP Streamable HTTP transport sends POST SSE responses with a priming event containing retry: 3000. When the POST stream ends (after delivering the response), the browser's EventSource API automatically reconnects via GET. This creates multiple competing EventSource connections:
              1. The initial standalone GET stream (primary notification channel)
              2. Reconnecting GETs from completed POST responses (initialize, tools/list, etc.)
              Each reconnecting GET calls resume() which unconditionally replaces self.common.tx:
              // Before fix — local.rs resume()None => {let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);self.common.tx = tx;// ← Unconditionally replaces sender, kills other stream// ...}
              Dropping the old sender closes the old receiver, terminating the OTHER EventSource's stream. That stream then reconnects, replacing the sender again. Both leapfrog every sse_retry (3s) indefinitely.
              The Leapfrog Loop
              1. Client POST initialize → SSE response with priming (retry: 3000) → stream ends
2. Client GET (standalone) → becomes primary common channel (tx1/rx1)
3. POST EventSource reconnects via GET (3s later) → replaces common.tx → kills rx1
4. GET from step 2 reconnects → replaces common.tx → kills stream from step 3
5. Repeat every 3 seconds indefinitely

              Server logs confirm the pattern — alternating GET requests every 3 seconds with different Last-Event-ID values:
              13:33:51.670 GET Last-Event-ID: 0/2 ← from completed POST response
13:33:54.668 GET Last-Event-ID: 0 ← from killed standalone stream
13:33:57.679 GET Last-Event-ID: 0/2 ← leapfrog
13:34:00.674 GET Last-Event-ID: 0 ← leapfrog
...

              Additional Issue: Cache Replay Loop
              Even without the leapfrog, resume() called sync() on the common channel to replay cached events. Replaying server-initiated list_changed notifications caused clients to re-process old signals, triggering unnecessary re-fetches every reconnection cycle.
              What Happens in Practice
              Cursor (infinite loop)
              • Connects via POST initialize + GET standalone
              • POST SSE stream ends → EventSource reconnects via GET
              • Two competing streams leapfrog every 3 seconds
              • Server flooded with GET requests indefinitely
              • Notifications intermittently lost as channels are swapped
              VS Code (silent notification loss)
              • Reconnects SSE every ~5 minutes with same session ID
              • Each reconnection replaces the channel sender
              • Previous stream's receiver is orphaned
              • notify_tool_list_changed().await returns Ok(()) — silent failure
              Fix: Shadow Channels
              PR: #660
              Instead of unconditionally replacing the common channel, check if the primary is still active:
              • Primary dead (tx.is_closed()) → Replace it. New stream becomes primary.
              • Primary alive → Create a shadow stream — an idle SSE connection kept alive by SSE keep-alive pings that does NOT receive notifications and does NOT replace the primary channel.
              fnresume_or_shadow_common(&mutself) -> Result<StreamableHttpMessageReceiver,SessionError>{let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);ifself.common.tx.is_closed(){// Primary is dead — replace itself.common.tx = tx;}else{// Primary is alive — create shadow (idle, keep-alive only)self.shadow_txs.push(tx);}Ok(StreamableHttpMessageReceiver{http_request_id:None,inner: rx })}
              Why Not 409 Conflict?
              The initial approach (matching the TypeScript SDK) was to return 409 Conflict on duplicate standalone streams. However:
              1. The MCP spec states: "The client MAY remain connected to multiple SSE streams simultaneously" — 409 is not spec-compliant
              2. 409 causes Cursor to fail entirely on reconnection (500 errors from unhandled Conflict)
              3. The reconnecting EventSources are legitimate HTTP requests — they need a valid stream back
              Shadow channels are the correct approach: keep all connections alive without interference.
              Why No Cache Replay on Common Channel?
              Common channel notifications (tools/list_changed, resources/list_changed) are idempotent signals. Replaying cached ones causes clients to re-process old events, triggering unnecessary re-fetches or infinite notification loops. Missing one is harmless — the next real event arrives naturally. Request-wise channels still use sync() for proper response replay.
              Changes (5 commits)
              CommitDescription
              8bd424eInitial 409 Conflict approach (returned error on duplicate standalone stream)
              0d03eb5Handle resume with completed request-wise channels (fall through to common)
              a7bb822Remove 409 Conflict — allow channel replacement per MCP spec
              7cf5406Skip cache replay (sync) when replacing active streams
              a7df58cShadow channels — the final fix that prevents the leapfrog loop
              Files Changed
              • crates/rmcp/src/transport/streamable_http_server/session/local.rs
                • Added shadow_txs: Vec<Sender<ServerSseMessage>> to LocalSessionWorker
                • New method resume_or_shadow_common() with primary-alive check
                • Updated resume() to use shadow logic for both direct common and request-wise fallback paths
                • Removed sync() calls on common channel resume
                • Updated close_sse_stream() to clear shadow senders
                • Updated create_local_session() to initialize shadow_txs
              Test Results
              •  Cursor connects and initializes successfully (no 409/500 errors)
              •  Cursor does NOT enter infinite GET reconnect loop after connection
              •  Feature changes trigger exactly one batch of list_changed notifications
              •  Cursor receives and processes notifications correctly (re-fetches tools/resources)
              •  No notification replay loop (no repeated ResourceListChanged every 3s)
              •  VS Code connects and works correctly (unaffected by changes)
              • cargo check --workspace passes
              Environment
              • rmcp 0.15.0 (also affects 0.14.0)
              • StreamableHttpService with stateful_mode: true
              • LocalSessionManager (default session manager)
              • Clients tested: Cursor 2.4.37, VS Code MCP Extension
              Metadata
              Metadata
              Assignees
              No one assigned
                Labels
                No labels
                No labels
                Type
                No type
                Projects
                No projects
                  Milestone
                  No milestone
                  Relationships
                  None yet
                  Development
                  No branches or pull requests
                  Issue actions
                  
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Streamable HTTP: Multiple SSE streams cause infinite reconnect loop · Issue #659 · modelcontextprotocol/rust-sdk · GitHub
                  Skip to content
                  Streamable HTTP: Multiple SSE streams cause infinite reconnect loop #659
                  Closed
                  Closed
                  Streamable HTTP: Multiple SSE streams cause infinite reconnect loop#659
                  Description
                  @its-mash
                  its-mash
                  opened on Feb 14, 2026
                  Summary
                  When multiple SSE streams exist for the same session (e.g. from POST response reconnections), LocalSessionWorker::resume() unconditionally replaces self.common.tx, killing the other stream's receiver. Both EventSource connections then reconnect every sse_retry seconds, leapfrogging each other in an infinite loop that floods the server with GET requests.
                  Affected versions: rmcp 0.14.0, 0.15.0
                  Severity: Critical — causes infinite reconnect loops with clients like Cursor, and breaks server-to-client notifications over Streamable HTTP
                  Root Cause
                  The MCP Streamable HTTP transport sends POST SSE responses with a priming event containing retry: 3000. When the POST stream ends (after delivering the response), the browser's EventSource API automatically reconnects via GET. This creates multiple competing EventSource connections:
                  1. The initial standalone GET stream (primary notification channel)
                  2. Reconnecting GETs from completed POST responses (initialize, tools/list, etc.)
                  Each reconnecting GET calls resume() which unconditionally replaces self.common.tx:
                  // Before fix — local.rs resume()None => {let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);self.common.tx = tx;// ← Unconditionally replaces sender, kills other stream// ...}
                  Dropping the old sender closes the old receiver, terminating the OTHER EventSource's stream. That stream then reconnects, replacing the sender again. Both leapfrog every sse_retry (3s) indefinitely.
                  The Leapfrog Loop
                  1. Client POST initialize → SSE response with priming (retry: 3000) → stream ends
2. Client GET (standalone) → becomes primary common channel (tx1/rx1)
3. POST EventSource reconnects via GET (3s later) → replaces common.tx → kills rx1
4. GET from step 2 reconnects → replaces common.tx → kills stream from step 3
5. Repeat every 3 seconds indefinitely

                  Server logs confirm the pattern — alternating GET requests every 3 seconds with different Last-Event-ID values:
                  13:33:51.670 GET Last-Event-ID: 0/2 ← from completed POST response
13:33:54.668 GET Last-Event-ID: 0 ← from killed standalone stream
13:33:57.679 GET Last-Event-ID: 0/2 ← leapfrog
13:34:00.674 GET Last-Event-ID: 0 ← leapfrog
...

                  Additional Issue: Cache Replay Loop
                  Even without the leapfrog, resume() called sync() on the common channel to replay cached events. Replaying server-initiated list_changed notifications caused clients to re-process old signals, triggering unnecessary re-fetches every reconnection cycle.
                  What Happens in Practice
                  Cursor (infinite loop)
                  • Connects via POST initialize + GET standalone
                  • POST SSE stream ends → EventSource reconnects via GET
                  • Two competing streams leapfrog every 3 seconds
                  • Server flooded with GET requests indefinitely
                  • Notifications intermittently lost as channels are swapped
                  VS Code (silent notification loss)
                  • Reconnects SSE every ~5 minutes with same session ID
                  • Each reconnection replaces the channel sender
                  • Previous stream's receiver is orphaned
                  • notify_tool_list_changed().await returns Ok(()) — silent failure
                  Fix: Shadow Channels
                  PR: #660
                  Instead of unconditionally replacing the common channel, check if the primary is still active:
                  • Primary dead (tx.is_closed()) → Replace it. New stream becomes primary.
                  • Primary alive → Create a shadow stream — an idle SSE connection kept alive by SSE keep-alive pings that does NOT receive notifications and does NOT replace the primary channel.
                  fnresume_or_shadow_common(&mutself) -> Result<StreamableHttpMessageReceiver,SessionError>{let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);ifself.common.tx.is_closed(){// Primary is dead — replace itself.common.tx = tx;}else{// Primary is alive — create shadow (idle, keep-alive only)self.shadow_txs.push(tx);}Ok(StreamableHttpMessageReceiver{http_request_id:None,inner: rx })}
                  Why Not 409 Conflict?
                  The initial approach (matching the TypeScript SDK) was to return 409 Conflict on duplicate standalone streams. However:
                  1. The MCP spec states: "The client MAY remain connected to multiple SSE streams simultaneously" — 409 is not spec-compliant
                  2. 409 causes Cursor to fail entirely on reconnection (500 errors from unhandled Conflict)
                  3. The reconnecting EventSources are legitimate HTTP requests — they need a valid stream back
                  Shadow channels are the correct approach: keep all connections alive without interference.
                  Why No Cache Replay on Common Channel?
                  Common channel notifications (tools/list_changed, resources/list_changed) are idempotent signals. Replaying cached ones causes clients to re-process old events, triggering unnecessary re-fetches or infinite notification loops. Missing one is harmless — the next real event arrives naturally. Request-wise channels still use sync() for proper response replay.
                  Changes (5 commits)
                  CommitDescription
                  8bd424eInitial 409 Conflict approach (returned error on duplicate standalone stream)
                  0d03eb5Handle resume with completed request-wise channels (fall through to common)
                  a7bb822Remove 409 Conflict — allow channel replacement per MCP spec
                  7cf5406Skip cache replay (sync) when replacing active streams
                  a7df58cShadow channels — the final fix that prevents the leapfrog loop
                  Files Changed
                  • crates/rmcp/src/transport/streamable_http_server/session/local.rs
                    • Added shadow_txs: Vec<Sender<ServerSseMessage>> to LocalSessionWorker
                    • New method resume_or_shadow_common() with primary-alive check
                    • Updated resume() to use shadow logic for both direct common and request-wise fallback paths
                    • Removed sync() calls on common channel resume
                    • Updated close_sse_stream() to clear shadow senders
                    • Updated create_local_session() to initialize shadow_txs
                  Test Results
                  •  Cursor connects and initializes successfully (no 409/500 errors)
                  •  Cursor does NOT enter infinite GET reconnect loop after connection
                  •  Feature changes trigger exactly one batch of list_changed notifications
                  •  Cursor receives and processes notifications correctly (re-fetches tools/resources)
                  •  No notification replay loop (no repeated ResourceListChanged every 3s)
                  •  VS Code connects and works correctly (unaffected by changes)
                  • cargo check --workspace passes
                  Environment
                  • rmcp 0.15.0 (also affects 0.14.0)
                  • StreamableHttpService with stateful_mode: true
                  • LocalSessionManager (default session manager)
                  • Clients tested: Cursor 2.4.37, VS Code MCP Extension
                  Metadata
                  Metadata
                  Assignees
                  No one assigned
                    Labels
                    No labels
                    No labels
                    Type
                    No type
                    Projects
                    No projects
                      Milestone
                      No milestone
                      Relationships
                      None yet
                      Development
                      No branches or pull requests
                      Issue actions
                      
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Streamable HTTP: Multiple SSE streams cause infinite reconnect loop · Issue #659 · modelcontextprotocol/rust-sdk · GitHub
                      Skip to content
                      Streamable HTTP: Multiple SSE streams cause infinite reconnect loop #659
                      Closed
                      Closed
                      Streamable HTTP: Multiple SSE streams cause infinite reconnect loop#659
                      Description
                      @its-mash
                      its-mash
                      opened on Feb 14, 2026
                      Summary
                      When multiple SSE streams exist for the same session (e.g. from POST response reconnections), LocalSessionWorker::resume() unconditionally replaces self.common.tx, killing the other stream's receiver. Both EventSource connections then reconnect every sse_retry seconds, leapfrogging each other in an infinite loop that floods the server with GET requests.
                      Affected versions: rmcp 0.14.0, 0.15.0
                      Severity: Critical — causes infinite reconnect loops with clients like Cursor, and breaks server-to-client notifications over Streamable HTTP
                      Root Cause
                      The MCP Streamable HTTP transport sends POST SSE responses with a priming event containing retry: 3000. When the POST stream ends (after delivering the response), the browser's EventSource API automatically reconnects via GET. This creates multiple competing EventSource connections:
                      1. The initial standalone GET stream (primary notification channel)
                      2. Reconnecting GETs from completed POST responses (initialize, tools/list, etc.)
                      Each reconnecting GET calls resume() which unconditionally replaces self.common.tx:
                      // Before fix — local.rs resume()None => {let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);self.common.tx = tx;// ← Unconditionally replaces sender, kills other stream// ...}
                      Dropping the old sender closes the old receiver, terminating the OTHER EventSource's stream. That stream then reconnects, replacing the sender again. Both leapfrog every sse_retry (3s) indefinitely.
                      The Leapfrog Loop
                      1. Client POST initialize → SSE response with priming (retry: 3000) → stream ends
2. Client GET (standalone) → becomes primary common channel (tx1/rx1)
3. POST EventSource reconnects via GET (3s later) → replaces common.tx → kills rx1
4. GET from step 2 reconnects → replaces common.tx → kills stream from step 3
5. Repeat every 3 seconds indefinitely

                      Server logs confirm the pattern — alternating GET requests every 3 seconds with different Last-Event-ID values:
                      13:33:51.670 GET Last-Event-ID: 0/2 ← from completed POST response
13:33:54.668 GET Last-Event-ID: 0 ← from killed standalone stream
13:33:57.679 GET Last-Event-ID: 0/2 ← leapfrog
13:34:00.674 GET Last-Event-ID: 0 ← leapfrog
...

                      Additional Issue: Cache Replay Loop
                      Even without the leapfrog, resume() called sync() on the common channel to replay cached events. Replaying server-initiated list_changed notifications caused clients to re-process old signals, triggering unnecessary re-fetches every reconnection cycle.
                      What Happens in Practice
                      Cursor (infinite loop)
                      • Connects via POST initialize + GET standalone
                      • POST SSE stream ends → EventSource reconnects via GET
                      • Two competing streams leapfrog every 3 seconds
                      • Server flooded with GET requests indefinitely
                      • Notifications intermittently lost as channels are swapped
                      VS Code (silent notification loss)
                      • Reconnects SSE every ~5 minutes with same session ID
                      • Each reconnection replaces the channel sender
                      • Previous stream's receiver is orphaned
                      • notify_tool_list_changed().await returns Ok(()) — silent failure
                      Fix: Shadow Channels
                      PR: #660
                      Instead of unconditionally replacing the common channel, check if the primary is still active:
                      • Primary dead (tx.is_closed()) → Replace it. New stream becomes primary.
                      • Primary alive → Create a shadow stream — an idle SSE connection kept alive by SSE keep-alive pings that does NOT receive notifications and does NOT replace the primary channel.
                      fnresume_or_shadow_common(&mutself) -> Result<StreamableHttpMessageReceiver,SessionError>{let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);ifself.common.tx.is_closed(){// Primary is dead — replace itself.common.tx = tx;}else{// Primary is alive — create shadow (idle, keep-alive only)self.shadow_txs.push(tx);}Ok(StreamableHttpMessageReceiver{http_request_id:None,inner: rx })}
                      Why Not 409 Conflict?
                      The initial approach (matching the TypeScript SDK) was to return 409 Conflict on duplicate standalone streams. However:
                      1. The MCP spec states: "The client MAY remain connected to multiple SSE streams simultaneously" — 409 is not spec-compliant
                      2. 409 causes Cursor to fail entirely on reconnection (500 errors from unhandled Conflict)
                      3. The reconnecting EventSources are legitimate HTTP requests — they need a valid stream back
                      Shadow channels are the correct approach: keep all connections alive without interference.
                      Why No Cache Replay on Common Channel?
                      Common channel notifications (tools/list_changed, resources/list_changed) are idempotent signals. Replaying cached ones causes clients to re-process old events, triggering unnecessary re-fetches or infinite notification loops. Missing one is harmless — the next real event arrives naturally. Request-wise channels still use sync() for proper response replay.
                      Changes (5 commits)
                      CommitDescription
                      8bd424eInitial 409 Conflict approach (returned error on duplicate standalone stream)
                      0d03eb5Handle resume with completed request-wise channels (fall through to common)
                      a7bb822Remove 409 Conflict — allow channel replacement per MCP spec
                      7cf5406Skip cache replay (sync) when replacing active streams
                      a7df58cShadow channels — the final fix that prevents the leapfrog loop
                      Files Changed
                      • crates/rmcp/src/transport/streamable_http_server/session/local.rs
                        • Added shadow_txs: Vec<Sender<ServerSseMessage>> to LocalSessionWorker
                        • New method resume_or_shadow_common() with primary-alive check
                        • Updated resume() to use shadow logic for both direct common and request-wise fallback paths
                        • Removed sync() calls on common channel resume
                        • Updated close_sse_stream() to clear shadow senders
                        • Updated create_local_session() to initialize shadow_txs
                      Test Results
                      •  Cursor connects and initializes successfully (no 409/500 errors)
                      •  Cursor does NOT enter infinite GET reconnect loop after connection
                      •  Feature changes trigger exactly one batch of list_changed notifications
                      •  Cursor receives and processes notifications correctly (re-fetches tools/resources)
                      •  No notification replay loop (no repeated ResourceListChanged every 3s)
                      •  VS Code connects and works correctly (unaffected by changes)
                      • cargo check --workspace passes
                      Environment
                      • rmcp 0.15.0 (also affects 0.14.0)
                      • StreamableHttpService with stateful_mode: true
                      • LocalSessionManager (default session manager)
                      • Clients tested: Cursor 2.4.37, VS Code MCP Extension
                      Metadata
                      Metadata
                      Assignees
                      No one assigned
                        Labels
                        No labels
                        No labels
                        Type
                        No type
                        Projects
                        No projects
                          Milestone
                          No milestone
                          Relationships
                          None yet
                          Development
                          No branches or pull requests
                          Issue actions
                          
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Streamable HTTP: Multiple SSE streams cause infinite reconnect loop · Issue #659 · modelcontextprotocol/rust-sdk · GitHub
                          Skip to content
                          Streamable HTTP: Multiple SSE streams cause infinite reconnect loop #659
                          Closed
                          Closed
                          Streamable HTTP: Multiple SSE streams cause infinite reconnect loop#659
                          Description
                          @its-mash
                          its-mash
                          opened on Feb 14, 2026
                          Summary
                          When multiple SSE streams exist for the same session (e.g. from POST response reconnections), LocalSessionWorker::resume() unconditionally replaces self.common.tx, killing the other stream's receiver. Both EventSource connections then reconnect every sse_retry seconds, leapfrogging each other in an infinite loop that floods the server with GET requests.
                          Affected versions: rmcp 0.14.0, 0.15.0
                          Severity: Critical — causes infinite reconnect loops with clients like Cursor, and breaks server-to-client notifications over Streamable HTTP
                          Root Cause
                          The MCP Streamable HTTP transport sends POST SSE responses with a priming event containing retry: 3000. When the POST stream ends (after delivering the response), the browser's EventSource API automatically reconnects via GET. This creates multiple competing EventSource connections:
                          1. The initial standalone GET stream (primary notification channel)
                          2. Reconnecting GETs from completed POST responses (initialize, tools/list, etc.)
                          Each reconnecting GET calls resume() which unconditionally replaces self.common.tx:
                          // Before fix — local.rs resume()None => {let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);self.common.tx = tx;// ← Unconditionally replaces sender, kills other stream// ...}
                          Dropping the old sender closes the old receiver, terminating the OTHER EventSource's stream. That stream then reconnects, replacing the sender again. Both leapfrog every sse_retry (3s) indefinitely.
                          The Leapfrog Loop
                          1. Client POST initialize → SSE response with priming (retry: 3000) → stream ends
2. Client GET (standalone) → becomes primary common channel (tx1/rx1)
3. POST EventSource reconnects via GET (3s later) → replaces common.tx → kills rx1
4. GET from step 2 reconnects → replaces common.tx → kills stream from step 3
5. Repeat every 3 seconds indefinitely

                          Server logs confirm the pattern — alternating GET requests every 3 seconds with different Last-Event-ID values:
                          13:33:51.670 GET Last-Event-ID: 0/2 ← from completed POST response
13:33:54.668 GET Last-Event-ID: 0 ← from killed standalone stream
13:33:57.679 GET Last-Event-ID: 0/2 ← leapfrog
13:34:00.674 GET Last-Event-ID: 0 ← leapfrog
...

                          Additional Issue: Cache Replay Loop
                          Even without the leapfrog, resume() called sync() on the common channel to replay cached events. Replaying server-initiated list_changed notifications caused clients to re-process old signals, triggering unnecessary re-fetches every reconnection cycle.
                          What Happens in Practice
                          Cursor (infinite loop)
                          • Connects via POST initialize + GET standalone
                          • POST SSE stream ends → EventSource reconnects via GET
                          • Two competing streams leapfrog every 3 seconds
                          • Server flooded with GET requests indefinitely
                          • Notifications intermittently lost as channels are swapped
                          VS Code (silent notification loss)
                          • Reconnects SSE every ~5 minutes with same session ID
                          • Each reconnection replaces the channel sender
                          • Previous stream's receiver is orphaned
                          • notify_tool_list_changed().await returns Ok(()) — silent failure
                          Fix: Shadow Channels
                          PR: #660
                          Instead of unconditionally replacing the common channel, check if the primary is still active:
                          • Primary dead (tx.is_closed()) → Replace it. New stream becomes primary.
                          • Primary alive → Create a shadow stream — an idle SSE connection kept alive by SSE keep-alive pings that does NOT receive notifications and does NOT replace the primary channel.
                          fnresume_or_shadow_common(&mutself) -> Result<StreamableHttpMessageReceiver,SessionError>{let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);ifself.common.tx.is_closed(){// Primary is dead — replace itself.common.tx = tx;}else{// Primary is alive — create shadow (idle, keep-alive only)self.shadow_txs.push(tx);}Ok(StreamableHttpMessageReceiver{http_request_id:None,inner: rx })}
                          Why Not 409 Conflict?
                          The initial approach (matching the TypeScript SDK) was to return 409 Conflict on duplicate standalone streams. However:
                          1. The MCP spec states: "The client MAY remain connected to multiple SSE streams simultaneously" — 409 is not spec-compliant
                          2. 409 causes Cursor to fail entirely on reconnection (500 errors from unhandled Conflict)
                          3. The reconnecting EventSources are legitimate HTTP requests — they need a valid stream back
                          Shadow channels are the correct approach: keep all connections alive without interference.
                          Why No Cache Replay on Common Channel?
                          Common channel notifications (tools/list_changed, resources/list_changed) are idempotent signals. Replaying cached ones causes clients to re-process old events, triggering unnecessary re-fetches or infinite notification loops. Missing one is harmless — the next real event arrives naturally. Request-wise channels still use sync() for proper response replay.
                          Changes (5 commits)
                          CommitDescription
                          8bd424eInitial 409 Conflict approach (returned error on duplicate standalone stream)
                          0d03eb5Handle resume with completed request-wise channels (fall through to common)
                          a7bb822Remove 409 Conflict — allow channel replacement per MCP spec
                          7cf5406Skip cache replay (sync) when replacing active streams
                          a7df58cShadow channels — the final fix that prevents the leapfrog loop
                          Files Changed
                          • crates/rmcp/src/transport/streamable_http_server/session/local.rs
                            • Added shadow_txs: Vec<Sender<ServerSseMessage>> to LocalSessionWorker
                            • New method resume_or_shadow_common() with primary-alive check
                            • Updated resume() to use shadow logic for both direct common and request-wise fallback paths
                            • Removed sync() calls on common channel resume
                            • Updated close_sse_stream() to clear shadow senders
                            • Updated create_local_session() to initialize shadow_txs
                          Test Results
                          •  Cursor connects and initializes successfully (no 409/500 errors)
                          •  Cursor does NOT enter infinite GET reconnect loop after connection
                          •  Feature changes trigger exactly one batch of list_changed notifications
                          •  Cursor receives and processes notifications correctly (re-fetches tools/resources)
                          •  No notification replay loop (no repeated ResourceListChanged every 3s)
                          •  VS Code connects and works correctly (unaffected by changes)
                          • cargo check --workspace passes
                          Environment
                          • rmcp 0.15.0 (also affects 0.14.0)
                          • StreamableHttpService with stateful_mode: true
                          • LocalSessionManager (default session manager)
                          • Clients tested: Cursor 2.4.37, VS Code MCP Extension
                          Metadata
                          Metadata
                          Assignees
                          No one assigned
                            Labels
                            No labels
                            No labels
                            Type
                            No type
                            Projects
                            No projects
                              Milestone
                              No milestone
                              Relationships
                              None yet
                              Development
                              No branches or pull requests
                              Issue actions
                              
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Streamable HTTP: Multiple SSE streams cause infinite reconnect loop · Issue #659 · modelcontextprotocol/rust-sdk · GitHub
                              Skip to content
                              Streamable HTTP: Multiple SSE streams cause infinite reconnect loop #659
                              Closed
                              Closed
                              Streamable HTTP: Multiple SSE streams cause infinite reconnect loop#659
                              Description
                              @its-mash
                              its-mash
                              opened on Feb 14, 2026
                              Summary
                              When multiple SSE streams exist for the same session (e.g. from POST response reconnections), LocalSessionWorker::resume() unconditionally replaces self.common.tx, killing the other stream's receiver. Both EventSource connections then reconnect every sse_retry seconds, leapfrogging each other in an infinite loop that floods the server with GET requests.
                              Affected versions: rmcp 0.14.0, 0.15.0
                              Severity: Critical — causes infinite reconnect loops with clients like Cursor, and breaks server-to-client notifications over Streamable HTTP
                              Root Cause
                              The MCP Streamable HTTP transport sends POST SSE responses with a priming event containing retry: 3000. When the POST stream ends (after delivering the response), the browser's EventSource API automatically reconnects via GET. This creates multiple competing EventSource connections:
                              1. The initial standalone GET stream (primary notification channel)
                              2. Reconnecting GETs from completed POST responses (initialize, tools/list, etc.)
                              Each reconnecting GET calls resume() which unconditionally replaces self.common.tx:
                              // Before fix — local.rs resume()None => {let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);self.common.tx = tx;// ← Unconditionally replaces sender, kills other stream// ...}
                              Dropping the old sender closes the old receiver, terminating the OTHER EventSource's stream. That stream then reconnects, replacing the sender again. Both leapfrog every sse_retry (3s) indefinitely.
                              The Leapfrog Loop
                              1. Client POST initialize → SSE response with priming (retry: 3000) → stream ends
2. Client GET (standalone) → becomes primary common channel (tx1/rx1)
3. POST EventSource reconnects via GET (3s later) → replaces common.tx → kills rx1
4. GET from step 2 reconnects → replaces common.tx → kills stream from step 3
5. Repeat every 3 seconds indefinitely

                              Server logs confirm the pattern — alternating GET requests every 3 seconds with different Last-Event-ID values:
                              13:33:51.670 GET Last-Event-ID: 0/2 ← from completed POST response
13:33:54.668 GET Last-Event-ID: 0 ← from killed standalone stream
13:33:57.679 GET Last-Event-ID: 0/2 ← leapfrog
13:34:00.674 GET Last-Event-ID: 0 ← leapfrog
...

                              Additional Issue: Cache Replay Loop
                              Even without the leapfrog, resume() called sync() on the common channel to replay cached events. Replaying server-initiated list_changed notifications caused clients to re-process old signals, triggering unnecessary re-fetches every reconnection cycle.
                              What Happens in Practice
                              Cursor (infinite loop)
                              • Connects via POST initialize + GET standalone
                              • POST SSE stream ends → EventSource reconnects via GET
                              • Two competing streams leapfrog every 3 seconds
                              • Server flooded with GET requests indefinitely
                              • Notifications intermittently lost as channels are swapped
                              VS Code (silent notification loss)
                              • Reconnects SSE every ~5 minutes with same session ID
                              • Each reconnection replaces the channel sender
                              • Previous stream's receiver is orphaned
                              • notify_tool_list_changed().await returns Ok(()) — silent failure
                              Fix: Shadow Channels
                              PR: #660
                              Instead of unconditionally replacing the common channel, check if the primary is still active:
                              • Primary dead (tx.is_closed()) → Replace it. New stream becomes primary.
                              • Primary alive → Create a shadow stream — an idle SSE connection kept alive by SSE keep-alive pings that does NOT receive notifications and does NOT replace the primary channel.
                              fnresume_or_shadow_common(&mutself) -> Result<StreamableHttpMessageReceiver,SessionError>{let(tx, rx) = tokio::sync::mpsc::channel(self.session_config.channel_capacity);ifself.common.tx.is_closed(){// Primary is dead — replace itself.common.tx = tx;}else{// Primary is alive — create shadow (idle, keep-alive only)self.shadow_txs.push(tx);}Ok(StreamableHttpMessageReceiver{http_request_id:None,inner: rx })}
                              Why Not 409 Conflict?
                              The initial approach (matching the TypeScript SDK) was to return 409 Conflict on duplicate standalone streams. However:
                              1. The MCP spec states: "The client MAY remain connected to multiple SSE streams simultaneously" — 409 is not spec-compliant
                              2. 409 causes Cursor to fail entirely on reconnection (500 errors from unhandled Conflict)
                              3. The reconnecting EventSources are legitimate HTTP requests — they need a valid stream back
                              Shadow channels are the correct approach: keep all connections alive without interference.
                              Why No Cache Replay on Common Channel?
                              Common channel notifications (tools/list_changed, resources/list_changed) are idempotent signals. Replaying cached ones causes clients to re-process old events, triggering unnecessary re-fetches or infinite notification loops. Missing one is harmless — the next real event arrives naturally. Request-wise channels still use sync() for proper response replay.
                              Changes (5 commits)
                              CommitDescription
                              8bd424eInitial 409 Conflict approach (returned error on duplicate standalone stream)
                              0d03eb5Handle resume with completed request-wise channels (fall through to common)
                              a7bb822Remove 409 Conflict — allow channel replacement per MCP spec
                              7cf5406Skip cache replay (sync) when replacing active streams
                              a7df58cShadow channels — the final fix that prevents the leapfrog loop
                              Files Changed
                              • crates/rmcp/src/transport/streamable_http_server/session/local.rs
                                • Added shadow_txs: Vec<Sender<ServerSseMessage>> to LocalSessionWorker
                                • New method resume_or_shadow_common() with primary-alive check
                                • Updated resume() to use shadow logic for both direct common and request-wise fallback paths
                                • Removed sync() calls on common channel resume
                                • Updated close_sse_stream() to clear shadow senders
                                • Updated create_local_session() to initialize shadow_txs
                              Test Results
                              •  Cursor connects and initializes successfully (no 409/500 errors)
                              •  Cursor does NOT enter infinite GET reconnect loop after connection
                              •  Feature changes trigger exactly one batch of list_changed notifications
                              •  Cursor receives and processes notifications correctly (re-fetches tools/resources)
                              •  No notification replay loop (no repeated ResourceListChanged every 3s)
                              •  VS Code connects and works correctly (unaffected by changes)
                              • cargo check --workspace passes
                              Environment
                              • rmcp 0.15.0 (also affects 0.14.0)
                              • StreamableHttpService with stateful_mode: true
                              • LocalSessionManager (default session manager)
                              • Clients tested: Cursor 2.4.37, VS Code MCP Extension
                              Metadata
                              Metadata
                              Assignees
                              No one assigned
                                Labels
                                No labels
                                No labels
                                Type
                                No type
                                Projects
                                No projects
                                  Milestone
                                  No milestone
                                  Relationships
                                  None yet
                                  Development
                                  No branches or pull requests
                                  Issue actions