bug(lsp): `LspLifecycleManager` ignores `LspServerConfig.transport` field — always uses `StdioTransport` even when TCP is configured #3045

New issue

Open

opened 2026-04-05 04:15:08 +00:00 by freemo · 2 comments

freemo commented

2026-04-05 04:15:08 +00:00

Owner

Metadata

Branch: fix/lsp-lifecycle-tcp-transport
Commit Message: fix(lsp): honour LspServerConfig.transport field and implement TcpTransport
Milestone: v3.6.0
Parent Epic: #824

Background

During UAT testing of the LSP Integration feature area, a bug was discovered in src/cleveragents/lsp/lifecycle.py. The LspServerConfig.transport field (type LspTransport) is defined in the model layer and the specification mandates that it controls how the LSP runtime connects to a language server — either by spawning a subprocess over stdio or by connecting to an already-running server via a TCP socket. However, LspLifecycleManager never reads this field and unconditionally creates a StdioTransport in both start_server() and restart_server(). Additionally, no TcpTransport class exists anywhere in the codebase, so the tcp transport path is entirely unimplemented.

Users who configure transport: tcp in their LSP server YAML will have their configuration silently ignored — the server will be started as a subprocess via stdio instead of connecting to an existing TCP server.

Affected Code Locations

Location	Issue
`src/cleveragents/lsp/lifecycle.py` — `start_server()`	Always creates `StdioTransport`; `config.transport` never read
`src/cleveragents/lsp/lifecycle.py` — `restart_server()`	Same as above
`src/cleveragents/lsp/transport.py`	`TcpTransport` class is entirely missing
`src/cleveragents/lsp/models.py`	`LspTransport` enum defines `STDIO` and `TCP` values — model is correct

Reproduction

Configure an LSP server with transport: tcp in YAML. Call LspLifecycleManager.start_server(). Observe that a subprocess is spawned via stdio instead of a TCP connection being established.

# config.transport == LspTransport.TCP — but this is never checked:
transport = StdioTransport(
    command=config.command,
    args=config.args,
    env=config.env,
    cwd=workspace_path,
)

Subtasks

Write a failing Behave scenario in features/ that reproduces the bug: LspLifecycleManager.start_server() with transport=LspTransport.TCP must not create a StdioTransport
Implement TcpTransport class in src/cleveragents/lsp/transport.py with host: str and port: int fields, connecting to an already-running LSP server via TCP socket
Update LspLifecycleManager.start_server() to branch on config.transport: create StdioTransport when LspTransport.STDIO, create TcpTransport when LspTransport.TCP (using config.host and config.port from LspServerConfig)
Apply the same fix to LspLifecycleManager.restart_server() so it also respects config.transport
Add full type annotations to all new/modified code; ensure nox -e typecheck (Pyright strict) passes with zero errors
Extend Behave scenarios to cover the stdio path regression (existing behaviour must remain correct)
Verify nox -e coverage_report reports >= 97% coverage

Definition of Done

All subtasks above are completed and checked off
A failing Behave test was committed first (TDD), followed by the fix commit
TcpTransport is implemented and fully type-annotated in transport.py
LspLifecycleManager.start_server() and restart_server() correctly dispatch on config.transport
No # type: ignore suppressions introduced
All nox stages pass (nox -e lint, nox -e typecheck, nox -e unit_tests, nox -e integration_tests)
Coverage >= 97%
PR is linked to this issue and has at least two approvals before merge

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: ca-new-issue-creator

## Metadata - **Branch**: `fix/lsp-lifecycle-tcp-transport` - **Commit Message**: `fix(lsp): honour LspServerConfig.transport field and implement TcpTransport` - **Milestone**: v3.6.0 - **Parent Epic**: #824 ## Background During UAT testing of the LSP Integration feature area, a bug was discovered in `src/cleveragents/lsp/lifecycle.py`. The `LspServerConfig.transport` field (type `LspTransport`) is defined in the model layer and the specification mandates that it controls how the LSP runtime connects to a language server — either by spawning a subprocess over `stdio` or by connecting to an already-running server via a TCP socket. However, `LspLifecycleManager` never reads this field and unconditionally creates a `StdioTransport` in both `start_server()` and `restart_server()`. Additionally, no `TcpTransport` class exists anywhere in the codebase, so the `tcp` transport path is entirely unimplemented. Users who configure `transport: tcp` in their LSP server YAML will have their configuration silently ignored — the server will be started as a subprocess via stdio instead of connecting to an existing TCP server. ## Affected Code Locations | Location | Issue | |---|---| | `src/cleveragents/lsp/lifecycle.py` — `start_server()` | Always creates `StdioTransport`; `config.transport` never read | | `src/cleveragents/lsp/lifecycle.py` — `restart_server()` | Same as above | | `src/cleveragents/lsp/transport.py` | `TcpTransport` class is entirely missing | | `src/cleveragents/lsp/models.py` | `LspTransport` enum defines `STDIO` and `TCP` values — model is correct | ## Reproduction Configure an LSP server with `transport: tcp` in YAML. Call `LspLifecycleManager.start_server()`. Observe that a subprocess is spawned via stdio instead of a TCP connection being established. ```python # config.transport == LspTransport.TCP — but this is never checked: transport = StdioTransport( command=config.command, args=config.args, env=config.env, cwd=workspace_path, ) ``` ## Subtasks - [ ] Write a failing Behave scenario in `features/` that reproduces the bug: `LspLifecycleManager.start_server()` with `transport=LspTransport.TCP` must not create a `StdioTransport` - [ ] Implement `TcpTransport` class in `src/cleveragents/lsp/transport.py` with `host: str` and `port: int` fields, connecting to an already-running LSP server via TCP socket - [ ] Update `LspLifecycleManager.start_server()` to branch on `config.transport`: create `StdioTransport` when `LspTransport.STDIO`, create `TcpTransport` when `LspTransport.TCP` (using `config.host` and `config.port` from `LspServerConfig`) - [ ] Apply the same fix to `LspLifecycleManager.restart_server()` so it also respects `config.transport` - [ ] Add full type annotations to all new/modified code; ensure `nox -e typecheck` (Pyright strict) passes with zero errors - [ ] Extend Behave scenarios to cover the `stdio` path regression (existing behaviour must remain correct) - [ ] Verify `nox -e coverage_report` reports >= 97% coverage ## Definition of Done - [ ] All subtasks above are completed and checked off - [ ] A failing Behave test was committed first (TDD), followed by the fix commit - [ ] `TcpTransport` is implemented and fully type-annotated in `transport.py` - [ ] `LspLifecycleManager.start_server()` and `restart_server()` correctly dispatch on `config.transport` - [ ] No `# type: ignore` suppressions introduced - [ ] All nox stages pass (`nox -e lint`, `nox -e typecheck`, `nox -e unit_tests`, `nox -e integration_tests`) - [ ] Coverage >= 97% - [ ] PR is linked to this issue and has at least two approvals before merge --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-new-issue-creator

freemo added this to the v3.6.0 milestone

2026-04-05 04:15:13 +00:00

freemo added a new dependency

2026-04-05 04:15:24 +00:00

#824 Epic: LSP Functional Runtime

freemo commented

2026-04-05 04:16:12 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: Confirmed
MoSCoW: Should Have

Valid finding verified during batch triage.

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

Issue triaged by project owner: - **State**: Verified - **Priority**: Confirmed - **MoSCoW**: Should Have Valid finding verified during batch triage. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: ca-project-owner

freemo referenced this issue

2026-04-05 06:15:22 +00:00

[CA-AUTO] UAT Pool Supervisor — v3.2.0–v3.7.0 — Session Tracker #3094

freemo commented

2026-04-06 18:51:00 +00:00

Author

Owner

Milestone Triage Decision: Moved to Backlog

This spec alignment issue has been moved out of v3.3.0 during aggressive milestone triage. While important for consistency, it does not relate to the core focus of Corrections + Subplans + Checkpoints.

Reasoning:

v3.3.0 focus: Essential corrections, subplan management, and checkpoint functionality
This issue: Spec alignment for CLI output formatting - consistency improvement
Impact: Specification compliance, not core corrections/subplans/checkpoints functionality

Will be addressed in a future milestone focused on CLI specification compliance and consistency.

**Milestone Triage Decision: Moved to Backlog** This spec alignment issue has been moved out of v3.3.0 during aggressive milestone triage. While important for consistency, it does not relate to the core focus of Corrections + Subplans + Checkpoints. **Reasoning:** - v3.3.0 focus: Essential corrections, subplan management, and checkpoint functionality - This issue: Spec alignment for CLI output formatting - consistency improvement - Impact: Specification compliance, not core corrections/subplans/checkpoints functionality Will be addressed in a future milestone focused on CLI specification compliance and consistency.