Repository navigation
sse_client blocks indefinitely when server has incorrect base URL #447
Description
Activity
@Kudryavkaz I was able to replicate this issue
The issue in the screenshot I've added must be fixed, as the exception is not handled properly as you've mentioned.
@Kudryavkaz But the above client code, when incorrect URL is added, quits with unhandled error as mentioned in this comment. It is not blocked indefinitely. Can please provide more information about this indefinite block?
@kavinkumar807 Thank you for your reply.
If you start the example MCP server locally and connect the MCP client to "localhost:xxxx", you will not be able to reproduce this issue.
You should start the example MCP server on a remote server, and then use the MCP client to connect to that remote server.
"zhangfish.top" is my remote server, and I ran this command on it:

@Kudryavkaz Debugging the unhandled exception issue. Shall I use your endpoint to test?
@kavinkumar807 Sure, endpoint is "http://zhangfish.top:8080/sse"
@Kudryavkaz Thanks
@Kudryavkaz I could see there are two issue when I was debugging,
- The issue mentioned here, when I try to connect to the above mentioned url the deadlock situation happens and client is blocked instead of graceful shutdown -> has to be fixed :: I'm working on this
- The main reason for this exception is that with the above url client is able to make SSE connection but when checked with endpoint_url and url (as in the below screenshot) there is a mismatch
Logs
endpoint_url :: http://localhost:8080/messages?sessionId=18b0b6fb-b3e9-4faf-9350-e2b0d66d6549
url :: http://zhangfish.top:8080/sse
Endpoint origin does not match connection origin: http://localhost:8080/messages?sessionId=18b0b6fb-b3e9-4faf-9350-e2b0d66d6549
Error in sse_reader: Endpoint origin does not match connection origin: http://localhost:8080/messages?sessionId=18b0b6fb-b3e9-4faf-9350-e2b0d66d6549@dsp-ant @jspahrsummers the endpoint_url has to be
http://zhangfish.top:8080/messages?sessionId=18b0b6fb-b3e9-4faf-9350-e2b0d66d6549right? is it an issue or am I missing something?#410 seems like this issue is related to this. Adding here for reference
On further debugging as I've mentioned in the above comment the first point handling exception must be fixed, handling exception gracefully and quitting the client. But feel free to ignore the second point, that's my misunderstanding.
app.get('/sse', async (_: Request, res: Response) => { // set baseUrl for the transport const baseUrl = 'http://localhost:8080'; const transport = new SSEServerTransport(`${baseUrl}/messages`, res); transports[transport.sessionId] = transport; res.on('close', () => { delete transports[transport.sessionId]; }); await server.connect(transport); });@Kudryavkaz Here the baseUrl for the transport is added intentionally to demonstrate the indefinite blocking scenario right?
@kavinkumar807 yes.
Reacted by Kavin Kumar B@Kudryavkaz Raised PR #500 for the above issue.
Cc: @dsp-ant @jspahrsummers @nick-merrill @Kludex @jerome3o-anthropic
Note: adding the above people in cc from top contributors as I'm not sure who is the maintainer.
This issue has been open for a while and the linked PR has been closed #500
I'm curious if this is still a problem?
- addedbugSomething isn't workingSomething isn't workingneeds confirmationNeeds confirmation that the PR is actually required or needed.Needs confirmation that the PR is actually required or needed.
on Oct 3, 2025 - added 6 commits that reference this issue
on Mar 24, 2026


Describe the bug
When using the
sse_clientfunction to connect to a remote MCP server, if the MCP server sets an incorrect base URL (like http://localhost:8080), thesse_clientwill raise an exception in the following code:python-sdk/src/mcp/client/sse.py
Line 81 in c2ca8e0
The
read_stream_writerthen sends this exception to theread_stream:python-sdk/src/mcp/client/sse.py
Line 107 in c2ca8e0
However, since the
read_streamhas not been yielded yet, the exception will never be received.As a result, the
sse_clientwill be blocked indefinitely.To Reproduce
Expected behavior
The sse_client should raise an exception and exit gracefully.
Logs
None
Additional context
None