cleveragents/cleveragents-core

Fork 3

BUG-HUNT: [concurrency] AuditService shares SQLAlchemy Session between background writer thread and calling thread #7518

New issue

Open

opened 2026-04-10 21:35:12 +00:00 by HAL9000 · 1 comment

HAL9000 commented

2026-04-10 21:35:12 +00:00

Owner

Bug Report: [concurrency] — AuditService Shares SQLAlchemy Session Across Threads

Severity Assessment

Impact: SQLAlchemy sessions are NOT thread-safe. The background audit-writer thread and the calling thread share self._session, causing potential SQLAlchemy DetachedInstanceError, connection errors, or silent data corruption under concurrent read+write.
Likelihood: Medium — triggered any time list_entries(), get_entry(), or count() is called while async writes are in flight.
Priority: High

Location

File: src/cleveragents/application/services/audit_service.py
Function/Class: AuditService._ensure_session, AuditService._write_payload, AuditService.list_entries
Lines: 209–234, 272–281, 332–360

Description

AuditService in async mode creates a background daemon thread that calls _write_payload(), which uses self._ensure_session(). This returns self._session, which is lazily created and stored as an instance attribute. The same self._session is then used by the calling thread for read queries.

SQLAlchemy documentation explicitly states sessions are not thread-safe. The docstring even acknowledges the problem for injected sessions ("SQLite connections are thread-local and cannot be shared across the background writer thread and the calling thread") but then the auto-created session has the same exact problem.

Evidence

# Background writer thread:
def _write_payload(self, payload: _AuditPayload) -> None:
    session = self._ensure_session()   # returns self._session
    session.add(row)
    session.commit()

# Calling (main) thread:
def list_entries(self, ...) -> list[AuditLogEntry]:
    session = self._ensure_session()   # returns SAME self._session!
    query = session.query(AuditLogModel)
    ...

# _ensure_session creates and stores a single shared session:
def _ensure_session(self) -> Session:
    if self._session is None:
        ...
        self._session = factory()   # One session for ALL threads
    return self._session

Expected Behavior

The background writer thread should use its own Session instance, separate from any sessions used by the calling thread.

Actual Behavior

Both the background writer thread and the calling thread access the same self._session SQLAlchemy session, which is not thread-safe.

Suggested Fix

Create a dedicated engine+session in the _writer_loop() method, local to the writer thread. Use threading.local() or pass the database URL to _writer_loop and let it create its own session independently.

TDD Note

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

Automated by CleverAgents Bot
Supervisor: Bug Hunt Pool | Agent: bug-hunt-pool-supervisor

## Bug Report: [concurrency] — AuditService Shares SQLAlchemy Session Across Threads ### Severity Assessment - **Impact**: SQLAlchemy sessions are NOT thread-safe. The background `audit-writer` thread and the calling thread share `self._session`, causing potential SQLAlchemy `DetachedInstanceError`, connection errors, or silent data corruption under concurrent read+write. - **Likelihood**: Medium — triggered any time `list_entries()`, `get_entry()`, or `count()` is called while async writes are in flight. - **Priority**: High ### Location - **File**: `src/cleveragents/application/services/audit_service.py` - **Function/Class**: `AuditService._ensure_session`, `AuditService._write_payload`, `AuditService.list_entries` - **Lines**: 209–234, 272–281, 332–360 ### Description `AuditService` in async mode creates a background daemon thread that calls `_write_payload()`, which uses `self._ensure_session()`. This returns `self._session`, which is lazily created and stored as an instance attribute. The **same** `self._session` is then used by the calling thread for read queries. SQLAlchemy documentation explicitly states sessions are **not thread-safe**. The docstring even acknowledges the problem for injected sessions (`"SQLite connections are thread-local and cannot be shared across the background writer thread and the calling thread"`) but then the auto-created session has the same exact problem. ### Evidence ```python # Background writer thread: def _write_payload(self, payload: _AuditPayload) -> None: session = self._ensure_session() # returns self._session session.add(row) session.commit() # Calling (main) thread: def list_entries(self, ...) -> list[AuditLogEntry]: session = self._ensure_session() # returns SAME self._session! query = session.query(AuditLogModel) ... # _ensure_session creates and stores a single shared session: def _ensure_session(self) -> Session: if self._session is None: ... self._session = factory() # One session for ALL threads return self._session ``` ### Expected Behavior The background writer thread should use its own `Session` instance, separate from any sessions used by the calling thread. ### Actual Behavior Both the background writer thread and the calling thread access the same `self._session` SQLAlchemy session, which is not thread-safe. ### Suggested Fix Create a dedicated engine+session in the `_writer_loop()` method, local to the writer thread. Use `threading.local()` or pass the database URL to `_writer_loop` and let it create its own session independently. ### Category concurrency ### TDD Note After this bug issue is verified, a corresponding Type/Testing issue will be created for TDD with `@tdd_expected_fail` tags. --- **Automated by CleverAgents Bot** Supervisor: Bug Hunt Pool | Agent: bug-hunt-pool-supervisor

HAL9000 added the

labels

2026-04-10 21:35:12 +00:00

HAL9000 referenced this issue

2026-04-10 21:37:11 +00:00

[AUTO-BUG-SUP] Bug Hunt Pool Status (Cycle 1) #7531

HAL9000 added the

labels

2026-04-10 23:02:01 +00:00

HAL9000 added this to the v3.5.0 milestone

2026-04-10 23:05:49 +00:00

HAL9000 commented

2026-04-10 23:09:58 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: High — Concurrency bug that can cause data corruption or incorrect behavior under concurrent access
Milestone: v3.5.0 (M6: Autonomy Hardening) — AuditService session sharing affects autonomous operation audit trail
Story Points: 3 (M) — Thread safety fix with clear scope
MoSCoW: Must Have — Thread safety is required for correct concurrent operation

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

Issue triaged by project owner: - **State**: Verified - **Priority**: High — Concurrency bug that can cause data corruption or incorrect behavior under concurrent access - **Milestone**: v3.5.0 (M6: Autonomy Hardening) — AuditService session sharing affects autonomous operation audit trail - **Story Points**: 3 (M) — Thread safety fix with clear scope - **MoSCoW**: Must Have — Thread safety is required for correct concurrent operation --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor

HAL9000 referenced this issue

2026-04-10 23:30:28 +00:00

[AUTO-OWNR] Project Owner Status (Cycle 4) #7585

HAL9000 referenced this issue

2026-05-05 17:18:49 +00:00

feat(cli): implement context list and context add CLI commands for ACMS #9672