UAT: `LspRegistry` is in-memory only — LSP server registrations are lost between CLI invocations, violating spec's persistent global registry requirement #6838

New issue

Open

opened 2026-04-10 02:47:38 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-10 02:47:38 +00:00

Owner

Background and Context

UAT code analysis reveals that LspRegistry is an in-memory Python dict with no database persistence. The CLI module (lsp.py) even acknowledges this with a comment: # in-memory; replaced by DI container when production registry lands. This means every agents lsp add registration is lost when the process exits.

Current Behavior

src/cleveragents/cli/commands/lsp.py lines 77–85:

_registry: LspRegistry | None = None

def _get_registry() -> LspRegistry:
    """Get or create the module-level LspRegistry instance."""
    global _registry
    if _registry is None:
        _registry = LspRegistry()  # fresh in-memory dict every process
    return _registry

src/cleveragents/lsp/registry.py uses dict[str, LspServerConfig] with no I/O layer.

Result: Running agents lsp add --config pyright.yaml followed by agents lsp list in a new process returns "No LSP servers found." — the registration does not persist.

Expected Behavior (from spec §LSP Integration overview)

The spec states:

LSP servers are registered in a global LSP Registry (namespaced as [[server:]namespace/]name)

The word "global" combined with the spec's naming convention and the existence of agents lsp add / agents lsp list commands implies persistent storage, identical to the Tool Registry, Skill Registry, and Actor Registry — all of which persist registrations to SQLite via the repository/unit-of-work pattern (src/cleveragents/infrastructure/database/repositories.py, unit_of_work.py).

The LspServerConfig objects must be persisted to the application database so that:

agents lsp add persists the registration
agents lsp list / agents lsp show / agents lsp remove read from persistent storage
Registrations survive process restarts

Affected Code

src/cleveragents/lsp/registry.py: Pure in-memory dict — needs a repository abstraction backed by SQLite
src/cleveragents/cli/commands/lsp.py: Module-global _registry — needs to use DI container or persistent repository
Missing: Alembic migration for an lsp_servers table
Missing: LspServerRepository in src/cleveragents/infrastructure/database/repositories.py

Steps to Reproduce

agents lsp add --config lsp/pyright.yaml → "LSP server registered"
(In a new terminal / process) agents lsp list → "No LSP servers found."

Acceptance Criteria

agents lsp add writes LspServerConfig to the application database
agents lsp list, agents lsp show, agents lsp remove read from the database
LSP server registrations survive process restarts
Implementation follows the same repository/unit-of-work pattern used by Tool Registry and Actor Registry

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

## Background and Context UAT code analysis reveals that `LspRegistry` is an in-memory Python dict with no database persistence. The CLI module (`lsp.py`) even acknowledges this with a comment: `# in-memory; replaced by DI container when production registry lands`. This means every `agents lsp add` registration is lost when the process exits. ## Current Behavior `src/cleveragents/cli/commands/lsp.py` lines 77–85: ```python _registry: LspRegistry | None = None def _get_registry() -> LspRegistry: """Get or create the module-level LspRegistry instance.""" global _registry if _registry is None: _registry = LspRegistry() # fresh in-memory dict every process return _registry ``` `src/cleveragents/lsp/registry.py` uses `dict[str, LspServerConfig]` with no I/O layer. **Result:** Running `agents lsp add --config pyright.yaml` followed by `agents lsp list` in a new process returns "No LSP servers found." — the registration does not persist. ## Expected Behavior (from spec §LSP Integration overview) The spec states: > LSP servers are registered in a global **LSP Registry** (namespaced as `[[server:]namespace/]name`) The word "global" combined with the spec's naming convention and the existence of `agents lsp add` / `agents lsp list` commands implies persistent storage, identical to the Tool Registry, Skill Registry, and Actor Registry — all of which persist registrations to SQLite via the repository/unit-of-work pattern (`src/cleveragents/infrastructure/database/repositories.py`, `unit_of_work.py`). The `LspServerConfig` objects must be persisted to the application database so that: - `agents lsp add` persists the registration - `agents lsp list` / `agents lsp show` / `agents lsp remove` read from persistent storage - Registrations survive process restarts ## Affected Code - `src/cleveragents/lsp/registry.py`: Pure in-memory `dict` — needs a repository abstraction backed by SQLite - `src/cleveragents/cli/commands/lsp.py`: Module-global `_registry` — needs to use DI container or persistent repository - Missing: Alembic migration for an `lsp_servers` table - Missing: `LspServerRepository` in `src/cleveragents/infrastructure/database/repositories.py` ## Steps to Reproduce 1. `agents lsp add --config lsp/pyright.yaml` → "LSP server registered" 2. (In a new terminal / process) `agents lsp list` → "No LSP servers found." ## Acceptance Criteria - `agents lsp add` writes `LspServerConfig` to the application database - `agents lsp list`, `agents lsp show`, `agents lsp remove` read from the database - LSP server registrations survive process restarts - Implementation follows the same repository/unit-of-work pattern used by Tool Registry and Actor Registry --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-10 02:48:30 +00:00

HAL9000 added this to the v3.5.0 milestone

2026-04-10 02:48:30 +00:00

HAL9000 referenced this issue