modelcontextprotocol / modelcontextprotocol/python-sdk
ExceptionGroup wrapping obscures real errors from task groups
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 24.3k
- Forks
- 4k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 31
Description
Summary
When SDK internal anyio task group tasks fail, the real error is wrapped in a BaseExceptionGroup alongside Cancelled exceptions from cancelled sibling tasks. This makes error classification extremely difficult for callers — they cannot reliably determine the root cause of a failure.
There are 16 create_task_group() usages across the SDK with no except* syntax or ExceptionGroup unwrapping anywhere.
Expected Behavior
- Callers should receive the original exception, not an ExceptionGroup wrapping it alongside cancellation noise
- When a task group has one real failure and N cancelled siblings, only the real failure should propagate
Current Behavior
- A single connection failure produces a
BaseExceptionGroupcontaining the real error plus multipleCancelledexceptions - Callers must manually unwrap exception groups to find the root cause
- This affects ~80+ call sites across the SDK where task groups are used
Affected Code
src/mcp/shared/session.py(session task groups)src/mcp/client/streamable_http.py(transport task groups)- All other
create_task_group()sites
Related
- #1742 — broader typed error classes design
- #1830 — CancelledError indistinguishable from external cancellation (closed but related)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the task-group handling in src/mcp/shared/session.py and src/mcp/client/streamable_http.py, then inspect the other create_task_group() sites mentioned in the issue. Reproduce a connection failure with cancelled sibling tasks and verify that the real exception propagates without cancellation noise across the affected call sites.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100