github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 19:08:59 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #23750] perf: MCP tool server reconnects on every message causing 15-20s silent delay #35589

New Issue
Closed
opened 2026-04-25 09:46:17 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-25 09:46:17 -05:00
Owner
Copy Link

Originally created by @DSavaliya-gh on GitHub (Apr 15, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23750

Bug Description

When an MCP (Model Context Protocol) tool server is enabled in Open WebUI, every chat message triggers a full MCP connection lifecycle from scratch:

  1. MCPClient() -- new instance
  2. connect() -- TCP + TLS + HTTP session + MCP initialize() handshake (10 s timeout)
  3. list_tool_specs() -- full list_tools() round-trip

This happens before the model is ever called, and no status event is emitted to the frontend during this phase. The user sees a blinking dot for 15-20 seconds with zero feedback, followed by the model thinking phase.

Steps to Reproduce

  1. Add any MCP tool server in Admin Panel > Settings > Tools
  2. Assign that server to a model
  3. Start a new chat with that model
  4. Send any message (including follow-up messages in an existing conversation)

Expected Behavior

  • Blinking dot phase should be less than 2 s on warm follow-up messages
  • User should see a visible status like 'Connecting to [server]...' during any network wait

Actual Behavior

  • 15-20 second silent blinking dot on every single message, including follow-ups
  • Zero user-visible feedback during the MCP handshake phase

Root Cause

In backend/open_webui/utils/middleware.py, process_chat_payload reconnects every time:

mcp_clients[server_id] = MCPClient()
await mcp_clients[server_id].connect(...)
tool_specs = await mcp_clients[server_id].list_tool_specs()

No event_emitter call is made before this block -- the user sees nothing.

Fix (linked PR)

  1. Status events: emit type='status' with action='mcp_connect' before/after handshake
  2. Connection pooling for static bearer-auth servers: reuse the MCPClient session across messages via app.state.mcp_client_pool
Originally created by @DSavaliya-gh on GitHub (Apr 15, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23750 ## Bug Description When an MCP (Model Context Protocol) tool server is enabled in Open WebUI, every chat message triggers a **full MCP connection lifecycle from scratch**: 1. MCPClient() -- new instance 2. connect() -- TCP + TLS + HTTP session + MCP initialize() handshake (10 s timeout) 3. list_tool_specs() -- full list_tools() round-trip This happens **before** the model is ever called, and **no status event is emitted to the frontend** during this phase. The user sees a blinking dot for **15-20 seconds** with zero feedback, followed by the model thinking phase. ## Steps to Reproduce 1. Add any MCP tool server in Admin Panel > Settings > Tools 2. Assign that server to a model 3. Start a new chat with that model 4. Send any message (including follow-up messages in an existing conversation) ## Expected Behavior - Blinking dot phase should be less than 2 s on warm follow-up messages - User should see a visible status like 'Connecting to [server]...' during any network wait ## Actual Behavior - 15-20 second silent blinking dot on every single message, including follow-ups - Zero user-visible feedback during the MCP handshake phase ## Root Cause In backend/open_webui/utils/middleware.py, process_chat_payload reconnects every time: mcp_clients[server_id] = MCPClient() await mcp_clients[server_id].connect(...) tool_specs = await mcp_clients[server_id].list_tool_specs() No event_emitter call is made before this block -- the user sees nothing. ## Fix (linked PR) 1. Status events: emit type='status' with action='mcp_connect' before/after handshake 2. Connection pooling for static bearer-auth servers: reuse the MCPClient session across messages via app.state.mcp_client_pool
GiteaMirror commented 2026-04-25 09:46:18 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Apr 15, 2026):

STOP OPENING / SPAMMING THE ISSUES SECTION

<!-- gh-comment-id:4253230605 --> @Classic298 commented on GitHub (Apr 15, 2026): STOP OPENING / SPAMMING THE ISSUES SECTION
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#35589
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?