Skip to content

fix(http): drain SSE stream for connection reuse#790

Draft
DaleSeo wants to merge 3 commits intomainfrom
fix/streamable-http-connection-reuse
Draft

fix(http): drain SSE stream for connection reuse#790
DaleSeo wants to merge 3 commits intomainfrom
fix/streamable-http-connection-reuse

Conversation

@DaleSeo
Copy link
Copy Markdown
Member

@DaleSeo DaleSeo commented Apr 6, 2026

Fixes #789

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

@github-actions github-actions bot added T-test Testing related changes T-core Core library changes T-transport Transport layer changes labels Apr 6, 2026
DaleSeo added 2 commits April 5, 2026 21:56
The SseAutoReconnectStream wrapper introduces a 3-second reconnect
delay (from the priming event retry field) when the inner stream
ends, preventing the 50ms drain from completing. Use a thin
raw_sse_to_jsonrpc adapter for per-request POST SSE streams instead,
so the stream ends immediately when the server closes the channel.
POST SSE response bodies cannot be fully consumed before the next
request starts, causing reqwest to stall on pool checkout (~40ms).
The long-lived GET SSE stream already holds its own connection, so
there is no benefit to pooling POST connections with HTTP/1.1.

This matches the workaround reported in #789.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

T-core Core library changes T-test Testing related changes T-transport Transport layer changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

StreamableHttpClientTransport has 10x higher latency on subsequent calls vs Python SDK

1 participant