mirror of
https://github.com/open-webui/mcpo.git
synced 2026-07-22 19:55:24 -04:00
issue: SSE fails after 5 min of inactivity #35
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lowlyocean on GitHub (Apr 14, 2025).
Check Existing Issues
mcpo Version
v0.0.11
Open WebUI Version (if applicable)
No response
Operating System
Docker image
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
Recently merged PR for SSE support doesn't properly handle long-lived sessions. The MCP SSE client library has an sse_read_timeout default of 5 minutes.
After that, the session closes and subsequent tool calls fail.
mcpo either needs to set that timeout to Noneto maintain a long-lived connection, or else have logic to reconnect on-demand. Please see here for similar issue in a different MCP client:
https://github.com/home-assistant/core/issues/140667
Actual Behavior
SSE mode shouldn't fail to call tools after 5 minutes from the prior tool call
Steps to Reproduce
Launch with sse flag to connect to MCP server via SSE
Send a tool call
Wait at least 5 minutes and try another tool call
Notice you get an internal server error which is due to timeout of the SSE connection
Logs & Screenshots
N/A
Additional Information
No response
@lowlyocean commented on GitHub (Apr 14, 2025):
The fix could be as simple as this , i.e. sse_client(url=url, sse_read_timeout=None)
@PrideIsLife commented on GitHub (May 14, 2025):
A regression occured recently, the fix you introduced @lowlyocean was rolled back here
in the context of this PR.
FYI @tjbck
@lowlyocean commented on GitHub (May 14, 2025):
@taylorwilsdon was it necessary to remove the line that sets SSE read timeout to None? If not, can we please re-add what was there?
If you do need different behavior for your contribution, please make it conditional so that you don't affect the legacy SSE behavior
Probably should put this behind an automated regression test to prevent this going forward
@taylorwilsdon commented on GitHub (May 14, 2025):
Hm I'm not sure its a design best practice to just never timeout with no ability to configure it, especially given the spec and design patterns moving towards Streamable HTTP but I don't believe it's necessary to keep it for the new functionality to work - pr here to roll back @lowlyocean
https://github.com/open-webui/mcpo/pull/136
if you want to just restore it as is. Alternatively, maybe it should be configurable?
@lowlyocean commented on GitHub (May 14, 2025):
About the design preference of not leaving a connection open indefinitely, I agree with you. @tjbck may want to consider opening connections on-demand whenever they're needed (as the Home Assistant team decided to do with their connection to MCP here)
The solution we are talking about restoring is just low-hanging fruit to allow mcpo to not need a restart every 5 minutes
@taylorwilsdon commented on GitHub (May 14, 2025):
Reopening on demand is what it's doing now, no? If it goes down, the subsequent mcpo call would start the proc back up. Just adds an extra call - https://github.com/home-assistant/core/issues/140667#issuecomment-2727053915 seems like the current state. If you want a persistent/ongoing session,
Streamable HTTP is the right transport for it and you just need to change a line or two in your MCP. IMO that's the correct pattern for this use case, but I'm totally on board with reverting to previous behavior if it's causing any issues - personally don't feel strongly one way or another (perhaps if only because I'm not relying on anything mcpo for any sse that matches this pattern, anything persistent has been moved to Streamable HTTP haha)
@smarthomeblack commented on GitHub (Jul 18, 2025):
I don't understand why if I use gemini flash mode, it only works the first few times of connection, then it keeps reporting error Tool xxx not found. If I use pro model, there is no tool not found phenomenon.