BUG-HUNT: [concurrency] Inefficient timer creation in MCPRefreshHook #1324

Open
opened 2026-04-02 16:49:44 +00:00 by freemo · 0 comments
Owner

Bug Report: Concurrency — Potential for inefficient timer creation in MCPRefreshHook

Severity Assessment

  • Impact: In a scenario with a high rate of notifications, the creation of many short-lived timer threads could lead to performance degradation and increased memory usage.
  • Likelihood: Low, as it requires a "storm" of notifications from the MCP server.
  • Priority: Low

Location

  • File: src/cleveragents/mcp/refresh_hook.py
  • Function/Class: MCPRefreshHook._on_notification
  • Lines: 89-96

Description

The _on_notification method in MCPRefreshHook creates a new threading.Timer object for every notification received. While the logic correctly cancels the previous timer to implement debouncing, the creation of a new thread for each notification can be inefficient if notifications arrive at a very high frequency. This could lead to a large number of short-lived threads being created and destroyed, which can add overhead and potentially impact performance.

Evidence

        with self._lock:
            if self._timer is not None:
                self._timer.cancel()
            timer = threading.Timer(self._debounce_seconds, self._do_refresh)
            timer.daemon = True
            self._timer = timer

        timer.start()

Expected Behavior

A more efficient approach would be to use a single, shared timer or a different synchronization primitive that avoids the creation of a new thread for each event.

Suggested Fix

Instead of creating a new threading.Timer on each notification, a single worker thread with a condition variable or an event queue could be used. The notification handler would simply notify the worker thread, which would then handle the debouncing logic. This would avoid the overhead of creating and destroying threads for each notification.

Alternatively, a concurrent.futures.ThreadPoolExecutor with a single worker thread could be used to manage the execution of the refresh task.

Category

concurrency

## Bug Report: Concurrency — Potential for inefficient timer creation in MCPRefreshHook ### Severity Assessment - **Impact**: In a scenario with a high rate of notifications, the creation of many short-lived timer threads could lead to performance degradation and increased memory usage. - **Likelihood**: Low, as it requires a "storm" of notifications from the MCP server. - **Priority**: Low ### Location - **File**: `src/cleveragents/mcp/refresh_hook.py` - **Function/Class**: `MCPRefreshHook._on_notification` - **Lines**: 89-96 ### Description The `_on_notification` method in `MCPRefreshHook` creates a new `threading.Timer` object for every notification received. While the logic correctly cancels the previous timer to implement debouncing, the creation of a new thread for each notification can be inefficient if notifications arrive at a very high frequency. This could lead to a large number of short-lived threads being created and destroyed, which can add overhead and potentially impact performance. ### Evidence ```python with self._lock: if self._timer is not None: self._timer.cancel() timer = threading.Timer(self._debounce_seconds, self._do_refresh) timer.daemon = True self._timer = timer timer.start() ``` ### Expected Behavior A more efficient approach would be to use a single, shared timer or a different synchronization primitive that avoids the creation of a new thread for each event. ### Suggested Fix Instead of creating a new `threading.Timer` on each notification, a single worker thread with a condition variable or an event queue could be used. The notification handler would simply notify the worker thread, which would then handle the debouncing logic. This would avoid the overhead of creating and destroying threads for each notification. Alternatively, a `concurrent.futures.ThreadPoolExecutor` with a single worker thread could be used to manage the execution of the refresh task. ### Category concurrency
freemo self-assigned this 2026-04-02 18:45:23 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cleveragents/cleveragents-core#1324
No description provided.