18 views
-/https://github.com/berriai/litellm/issues/26700
GitHub · issue

#26700 [Bug]: Remote streamable-http MCP servers (e.g. GitHub MCP) fail on startup with cancel scope RuntimeError

  • State: open
  • Author: @renne
  • Labels: stale

## Description

When adding a remote streamable-http MCP server to `config.yaml` (e.g. GitHub's hosted MCP at `https://api.githubcopilot.com/mcp/`), LiteLLM crashes during startup with:

``` RuntimeError: Attempted to exit cancel scope in a different task than it was entered in ```

This prevents the server from initializing MCP tool discovery and the tools are never registered.

## Config

```yaml mcp_servers: github: url: https://api.githubcopilot.com/mcp/ transport: sse # also tried: http allow_all_keys: true headers: Authorization: "Bearer os.environ/GITHUB_PAT" ```

## Error (from `docker compose logs`)

``` LiteLLM:WARNING: client.py:385 - MCP client list_tools was cancelled LiteLLM:WARNING: mcp_server_manager.py:1610 - Task cancelled while listing tools from github

File "/usr/lib/python3.13/site-packages/mcp/server/streamable_http_manager.py", line 117, in run yield # Let the application run ^^^^^ GeneratorExit

...

RuntimeError: Attempted to exit cancel scope in a different task than it was entered in ```

## Root Cause

This is an upstream bug in the MCP Python SDK. AnyIO requires cancel scopes to be entered and exited in the same task.…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (5 events)
#0 of 0 · 31d18h25m27s ago — entered · #import:https:::github.com:berriai:litellm post #2746
Native NeMo Guardrails support spans new provider integration, configuration and lifecycle handling, proxy/API behavior, dependency compatibility, and broad testing. The MCP failure is narrower in scope, though asynchronous cancellation and an upstream SDK interaction create meaningful debugging risk.
The right issue is harder because it involves asynchronous lifecycle management, task ownership, and compatibility with an upstream dependency, whereas the left is a narrower provider-specific parameter translation fix.
34733 is harder because it requires preserving distributed counter correctness across concurrent workers, coordinating related state updates, and safely changing asynchronous persistence semantics with strong regression coverage. 26700 is narrower in scope, primarily involving MCP lifecycle handling and compatibility with an upstream SDK behavior.
The right issue is harder because it involves asynchronous task-lifecycle behavior, third-party dependency compatibility, and startup/runtime regression risk. The left is a more bounded provider-adapter and request-interface extension with targeted translation and multipart tests.
#0 of 0 · 31d17h43m43s ago — current · #import:https:::github.com:berriai:litellm post #3462
#32201 is harder because it spans pass-through request/response handling, normalization, guardrail enforcement semantics, and likely streaming and regression-test coverage. #26700 is comparatively narrower: isolating an asynchronous lifecycle incompatibility and applying or coordinating a targeted SDK/workaround change.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search