cleveragents/cleveragents-core

Fork 3

BUG-HUNT: [concurrency] MCPToolAdapter.invoke() holds global RLock during blocking network I/O #7742

New issue

Open

opened 2026-04-12 03:22:31 +00:00 by HAL9000 · 3 comments

HAL9000 commented

2026-04-12 03:22:31 +00:00

Owner

Bug Report: Concurrency — `MCPToolAdapter.invoke()` Holds Global RLock During Blocking Transport Call

Severity Assessment

Impact: All threads sharing an MCPToolAdapter (including health-check timer threads, discover_tools callers, and any is_connected property access) are completely blocked for the entire duration of every MCP tool call. In practice this means health checks can never fire during tool execution, and parallel discovery is serialized behind tool execution.
Likelihood: High — the entire invoke() method body (lines 473–547) runs inside with self._lock:, including the blocking self._transport.call(...) at line 499.
Priority: High

Location

File: src/cleveragents/mcp/adapter.py
Function/Class: MCPToolAdapter.invoke
Lines: 473–547

Description

The MCPToolAdapter uses a single threading.RLock (self._lock) to protect all internal state. The invoke() method acquires this lock at line 473 and holds it for the entire method — including the blocking call to self._transport.call("tools/call", ...) on line 499, which is a network round-trip of indeterminate duration.

While the lock is held:

Any call to is_connected (property) blocks (it acquires self._lock).
Any call to discover_tools() blocks (it acquires self._lock).
Any call to capabilities or capability_metadata blocks.
Background health-check threads (McpClient._check_health calls discover_tools) block indefinitely.

This creates practical deadlock-like conditions in the McpClient health-monitor: the timer thread tries to call discover_tools() to probe health, but if a tool invocation is in progress, discover_tools can never acquire self._lock — health probes silently time out.

Evidence

# src/cleveragents/mcp/adapter.py lines 473-517
def invoke(self, tool_name: str, arguments: dict[str, Any]) -> MCPToolResult:
    with self._lock:           # <-- lock acquired here
        if not self._connected:
            ...
        descriptor = self._tools.get(tool_name)
        ...
        validation_error = self._validate_input(descriptor, arguments)
        ...
        start = time.monotonic()
        try:
            result = self._transport.call(   # <-- BLOCKING NETWORK I/O while lock held
                "tools/call",
                {"name": tool_name, "arguments": arguments},
            )
        ...
    # lock released here — after network round-trip completes

Expected Behavior

The lock should be held only for brief critical sections accessing shared mutable state (e.g., reading self._connected and self._tools). The blocking network call should happen outside the lock.

Actual Behavior

The entire invoke() body runs under self._lock, blocking all other adapter operations for the full duration of the MCP network call.

Suggested Fix

Copy needed state under the lock, release it, then perform the network call:

def invoke(self, tool_name: str, arguments: dict[str, Any]) -> MCPToolResult:
    with self._lock:
        if not self._connected:
            raise RuntimeError(...)
        descriptor = self._tools.get(tool_name)
        if descriptor is None:
            return MCPToolResult(success=False, error=...)
        validation_error = self._validate_input(descriptor, arguments)
        if validation_error:
            return MCPToolResult(success=False, error=...)
    # Lock released before blocking network call
    start = time.monotonic()
    try:
        result = self._transport.call("tools/call", {"name": tool_name, "arguments": arguments})
    except ...
    ...

TDD Note

After this bug issue is verified, a corresponding Type/Testing issue will be created for TDD.

Automated by CleverAgents Bot
Supervisor: Bug Hunting | Agent: bug-hunter

## Bug Report: Concurrency — `MCPToolAdapter.invoke()` Holds Global RLock During Blocking Transport Call ### Severity Assessment - **Impact**: All threads sharing an `MCPToolAdapter` (including health-check timer threads, `discover_tools` callers, and any `is_connected` property access) are completely blocked for the entire duration of every MCP tool call. In practice this means health checks can never fire during tool execution, and parallel discovery is serialized behind tool execution. - **Likelihood**: High — the entire `invoke()` method body (lines 473–547) runs inside `with self._lock:`, including the blocking `self._transport.call(...)` at line 499. - **Priority**: High ### Location - **File**: `src/cleveragents/mcp/adapter.py` - **Function/Class**: `MCPToolAdapter.invoke` - **Lines**: 473–547 ### Description The `MCPToolAdapter` uses a single `threading.RLock` (`self._lock`) to protect all internal state. The `invoke()` method acquires this lock at line 473 and holds it for the entire method — including the blocking call to `self._transport.call("tools/call", ...)` on line 499, which is a network round-trip of indeterminate duration. While the lock is held: - Any call to `is_connected` (property) blocks (it acquires `self._lock`). - Any call to `discover_tools()` blocks (it acquires `self._lock`). - Any call to `capabilities` or `capability_metadata` blocks. - Background health-check threads (`McpClient._check_health` calls `discover_tools`) block indefinitely. This creates practical deadlock-like conditions in the `McpClient` health-monitor: the timer thread tries to call `discover_tools()` to probe health, but if a tool invocation is in progress, `discover_tools` can never acquire `self._lock` — health probes silently time out. ### Evidence ```python # src/cleveragents/mcp/adapter.py lines 473-517 def invoke(self, tool_name: str, arguments: dict[str, Any]) -> MCPToolResult: with self._lock: # <-- lock acquired here if not self._connected: ... descriptor = self._tools.get(tool_name) ... validation_error = self._validate_input(descriptor, arguments) ... start = time.monotonic() try: result = self._transport.call( # <-- BLOCKING NETWORK I/O while lock held "tools/call", {"name": tool_name, "arguments": arguments}, ) ... # lock released here — after network round-trip completes ``` ### Expected Behavior The lock should be held only for brief critical sections accessing shared mutable state (e.g., reading `self._connected` and `self._tools`). The blocking network call should happen outside the lock. ### Actual Behavior The entire `invoke()` body runs under `self._lock`, blocking all other adapter operations for the full duration of the MCP network call. ### Suggested Fix Copy needed state under the lock, release it, then perform the network call: ```python def invoke(self, tool_name: str, arguments: dict[str, Any]) -> MCPToolResult: with self._lock: if not self._connected: raise RuntimeError(...) descriptor = self._tools.get(tool_name) if descriptor is None: return MCPToolResult(success=False, error=...) validation_error = self._validate_input(descriptor, arguments) if validation_error: return MCPToolResult(success=False, error=...) # Lock released before blocking network call start = time.monotonic() try: result = self._transport.call("tools/call", {"name": tool_name, "arguments": arguments}) except ... ... ``` ### Category concurrency ### TDD Note After this bug issue is verified, a corresponding Type/Testing issue will be created for TDD. --- **Automated by CleverAgents Bot** Supervisor: Bug Hunting | Agent: bug-hunter

HAL9000 added this to the v3.2.0 milestone

2026-04-12 03:41:54 +00:00

HAL9000 referenced this issue

2026-04-12 03:47:56 +00:00

[AUTO-PROJ-OWN] Project Owner Report (Cycle 1) #7724

HAL9000 added the

labels

2026-04-12 07:15:56 +00:00

freemo added the

Type

Bug

label

2026-04-12 18:33:48 +00:00

HAL9000 added

and removed

labels

2026-04-14 05:58:38 +00:00

HAL9000 commented

2026-04-14 05:58:38 +00:00

Author

Owner

✅ Verified — Concurrency bug: MCPToolAdapter.invoke() holds global RLock during blocking I/O — deadlock risk. MoSCoW: Must-have. Priority: High.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor

✅ **Verified** — Concurrency bug: MCPToolAdapter.invoke() holds global RLock during blocking I/O — deadlock risk. MoSCoW: Must-have. Priority: High. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor

HAL9000 commented

2026-04-14 06:11:54 +00:00

Author

Owner

✅ Verified — Concurrency bug: MCPToolAdapter.invoke() holds global RLock during blocking I/O — deadlock risk. MoSCoW: Must-have. Priority: High.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor