Remove legacy _task_capable_initialize() workaround#2612
Conversation
The function set experimental={"tasks": {}} but per the MCP spec:
1. Tasks belong in capabilities.tasks, not capabilities.experimental
2. Clients only need to declare task capabilities if receiving task-augmented
requests from the server (bi-directional support)
For client→server task requests (tools/call with task=True), only the server
needs to declare task capabilities. The SDK's native session.initialize()
handles this correctly.
marvin-context-protocol
Bot
added
enhancement
WalkthroughThe PR refactors the initialization flow in the MCP client. The Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
🧰 Additional context used📓 Path-based instructions (1)**/*.py📄 CodeRabbit inference engine (AGENTS.md)
Files:
🧠 Learnings (1)📓 Common learnings🧬 Code graph analysis (1)src/fastmcp/client/client.py (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
🔇 Additional comments (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Test Failure AnalysisSummary: The Windows test suite is timing out during initialization due to a SQLite database lock/hang in . Root Cause: The test in times out when creates a instance at . The timeout occurs during Despite the Suggested Solution: Option 1 - Mock DiskStore in auth provider tests (Recommended) # In tests/server/auth/providers/test_google.py
from unittest.mock import patch, MagicMock
@pytest.fixture(autouse=True)
def mock_disk_store():
with patch('fastmcp.server.auth.oauth_proxy.DiskStore') as mock:
mock.return_value = MagicMock()
yield mockOption 2 - Use in-memory storage for tests Option 3 - Increase timeout for Windows SQLite operations Detailed AnalysisStack TraceWhy This Happens on Windows
Related Files
Related Files
This analysis was generated automatically by the test failure triage bot. Workflow run: https://github.com/jlowin/fastmcp/actions/runs/20200715038 |
Test Failure AnalysisSummary: The Windows test suite is timing out during Root Cause: The test Despite the Suggested Solution: Option 1 - Mock DiskStore in auth provider tests (Recommended) # In tests/server/auth/providers/test_google.py or conftest.py
from unittest.mock import patch, MagicMock
@pytest.fixture(autouse=True)
def mock_disk_store():
with patch('fastmcp.server.auth.oauth_proxy.DiskStore') as mock:
mock.return_value = MagicMock()
yield mockOption 2 - Use in-memory storage for tests Option 3 - Increase timeout for Windows SQLite operations Detailed AnalysisStack TraceWhy This Happens on Windows
Related Files
Related Files
This analysis was generated automatically by the test failure triage bot. Workflow run: https://github.com/jlowin/fastmcp/actions/runs/20200715038 |
1 participant
FastMCP had a custom
_task_capable_initialize()function that setexperimental={"tasks": {}}during client initialization. This predates the finalized MCP spec, which clarifies:capabilities.tasks(now a first-class field)For client→server task requests (e.g.,
call_tool(..., task=True)), only the server declares task capabilities. The SDK's nativesession.initialize()handles this correctly, so we can remove the workaround.