UAT: `PluginManager.activate_plugin()` allows re-activating a `DEACTIVATED` plugin — spec state machine requires `DISCOVERED → ACTIVATED`, not `DEACTIVATED → ACTIVATED` #6058

New issue

Open

opened 2026-04-09 14:15:21 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-09 14:15:21 +00:00

Owner

Bug Report

Feature Area: Plugin Architecture — Plugin Lifecycle State Machine
Severity: Medium
Milestone: v3.6.0 (plugin architecture scope)

What Was Tested

Code-level analysis of src/cleveragents/infrastructure/plugins/manager.py — activate_plugin() and deactivate_plugin() methods, and src/cleveragents/infrastructure/plugins/types.py — PluginState enum with state transition diagram.

Expected Behavior (from spec / state diagram)

The PluginState docstring defines the state machine:

DISCOVERED ──► ACTIVATED ──► EXECUTING ──► ACTIVATED
              │                              │
              └──► DEACTIVATED              └──► ERRORED
              │                                   │
              └──► ERRORED                        └──► DEACTIVATED

The valid transitions are:

DISCOVERED → ACTIVATED (via activate_plugin())
ACTIVATED → DEACTIVATED (via deactivate_plugin())
ACTIVATED → ERRORED (on activation failure)
ERRORED → DEACTIVATED (via deactivate_plugin())

There is no DEACTIVATED → ACTIVATED transition in the spec state machine.

Actual Behavior (from code)

activate_plugin() only guards against re-activation of ACTIVATED state:

def activate_plugin(self, name: str) -> None:
    with self._lock:
        descriptor = self.get_plugin(name)

        if descriptor.state == PluginState.ACTIVATED:
            msg = f"Plugin '{name}' is already activated"
            raise PluginError(msg)  # ← only guards ACTIVATED

        # DEACTIVATED state is NOT guarded — falls through to activation
        if not descriptor.module_path or not descriptor.class_name:
            ...
        try:
            cls = self._loader.load_class(...)
            instance = cls()
            ...
            descriptor.state = PluginState.ACTIVATED  # ← DEACTIVATED → ACTIVATED allowed!

A plugin that has been deactivated (state = DEACTIVATED) can be re-activated by calling activate_plugin() again. This is not in the spec state machine.

Code Location

src/cleveragents/infrastructure/plugins/manager.py — activate_plugin() method.
src/cleveragents/infrastructure/plugins/types.py — PluginState state diagram.

Steps to Reproduce

Register a plugin: manager.register_plugin(descriptor)
Activate it: manager.activate_plugin(name) → state = ACTIVATED
Deactivate it: manager.deactivate_plugin(name) → state = DEACTIVATED
Re-activate it: manager.activate_plugin(name) → succeeds, state = ACTIVATED again
This violates the spec state machine which has no DEACTIVATED → ACTIVATED edge

Impact

The plugin lifecycle state machine is not enforced correctly
A deactivated plugin can be re-activated without going through DISCOVERED state
This may cause unexpected behavior if deactivation is intended to be permanent (e.g., for security reasons)
The state diagram in PluginState docstring is misleading about what transitions are actually enforced

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Bug Report **Feature Area**: Plugin Architecture — Plugin Lifecycle State Machine **Severity**: Medium **Milestone**: v3.6.0 (plugin architecture scope) ## What Was Tested Code-level analysis of `src/cleveragents/infrastructure/plugins/manager.py` — `activate_plugin()` and `deactivate_plugin()` methods, and `src/cleveragents/infrastructure/plugins/types.py` — `PluginState` enum with state transition diagram. ## Expected Behavior (from spec / state diagram) The `PluginState` docstring defines the state machine: ``` DISCOVERED ──► ACTIVATED ──► EXECUTING ──► ACTIVATED │ │ └──► DEACTIVATED └──► ERRORED │ │ └──► ERRORED └──► DEACTIVATED ``` The valid transitions are: - `DISCOVERED → ACTIVATED` (via `activate_plugin()`) - `ACTIVATED → DEACTIVATED` (via `deactivate_plugin()`) - `ACTIVATED → ERRORED` (on activation failure) - `ERRORED → DEACTIVATED` (via `deactivate_plugin()`) There is **no** `DEACTIVATED → ACTIVATED` transition in the spec state machine. ## Actual Behavior (from code) `activate_plugin()` only guards against re-activation of `ACTIVATED` state: ```python def activate_plugin(self, name: str) -> None: with self._lock: descriptor = self.get_plugin(name) if descriptor.state == PluginState.ACTIVATED: msg = f"Plugin '{name}' is already activated" raise PluginError(msg) # ← only guards ACTIVATED # DEACTIVATED state is NOT guarded — falls through to activation if not descriptor.module_path or not descriptor.class_name: ... try: cls = self._loader.load_class(...) instance = cls() ... descriptor.state = PluginState.ACTIVATED # ← DEACTIVATED → ACTIVATED allowed! ``` A plugin that has been deactivated (state = `DEACTIVATED`) can be re-activated by calling `activate_plugin()` again. This is not in the spec state machine. ## Code Location `src/cleveragents/infrastructure/plugins/manager.py` — `activate_plugin()` method. `src/cleveragents/infrastructure/plugins/types.py` — `PluginState` state diagram. ## Steps to Reproduce 1. Register a plugin: `manager.register_plugin(descriptor)` 2. Activate it: `manager.activate_plugin(name)` → state = `ACTIVATED` 3. Deactivate it: `manager.deactivate_plugin(name)` → state = `DEACTIVATED` 4. Re-activate it: `manager.activate_plugin(name)` → succeeds, state = `ACTIVATED` again 5. This violates the spec state machine which has no `DEACTIVATED → ACTIVATED` edge ## Impact - The plugin lifecycle state machine is not enforced correctly - A deactivated plugin can be re-activated without going through `DISCOVERED` state - This may cause unexpected behavior if deactivation is intended to be permanent (e.g., for security reasons) - The state diagram in `PluginState` docstring is misleading about what transitions are actually enforced --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 14:20:12 +00:00

HAL9000 added a new dependency

2026-04-09 14:24:09 +00:00

#5711 EPIC: Plugin Architecture Extensions — Plugin Manager, CLI & Lifecycle (v3.6.0)

HAL9000 referenced this issue

2026-04-09 14:24:22 +00:00