Race condition in MEMORY_ENGINES cache access #10537

Open
opened 2026-04-18 17:07:15 +00:00 by HAL9000 · 0 comments
Owner

Metadata

Commit: Latest commit in repository
Branch: main

Background and Context

The MEMORY_ENGINES module-level dictionary in src/cleveragents/infrastructure/database/engine_cache.py is accessed and modified without synchronization in src/cleveragents/infrastructure/database/unit_of_work.py (lines 76-84).

This creates a classic check-then-set race condition pattern that is not atomic. In multi-threaded scenarios (e.g., concurrent test execution), two threads could both pass the if check, both create engines, and the second write could overwrite the first, causing the first engine to be lost.

Expected Behavior

  • MEMORY_ENGINES dictionary access is thread-safe
  • Only one engine is created per unique database_url
  • In-memory SQLite databases are preserved across concurrent access
  • No data loss or corruption in multi-threaded test scenarios

Acceptance Criteria

  • A threading.Lock is added to protect MEMORY_ENGINES access
  • The lock is acquired before checking and modifying MEMORY_ENGINES
  • Concurrent access to the same in-memory database URL returns the same engine instance
  • Unit tests verify thread-safety with concurrent database access
  • No performance regression in single-threaded scenarios
  • Code review confirms the fix prevents the race condition

Subtasks

  • Add _MEMORY_ENGINES_LOCK = threading.Lock() to engine_cache.py
  • Wrap MEMORY_ENGINES access in unit_of_work.py with lock context manager
  • Write unit test for concurrent engine creation
  • Run full test suite to verify no regressions
  • Update any related documentation

Definition of Done

This issue is complete when:

  1. The threading.Lock is properly implemented around MEMORY_ENGINES access
  2. All acceptance criteria are met
  3. Unit tests pass with concurrent access scenarios
  4. Code review is approved
  5. Changes are merged to main branch

Automated by CleverAgents Bot
Agent: new-issue-creator

## Metadata **Commit:** Latest commit in repository **Branch:** main ## Background and Context The `MEMORY_ENGINES` module-level dictionary in `src/cleveragents/infrastructure/database/engine_cache.py` is accessed and modified without synchronization in `src/cleveragents/infrastructure/database/unit_of_work.py` (lines 76-84). This creates a classic check-then-set race condition pattern that is not atomic. In multi-threaded scenarios (e.g., concurrent test execution), two threads could both pass the `if` check, both create engines, and the second write could overwrite the first, causing the first engine to be lost. ## Expected Behavior - MEMORY_ENGINES dictionary access is thread-safe - Only one engine is created per unique database_url - In-memory SQLite databases are preserved across concurrent access - No data loss or corruption in multi-threaded test scenarios ## Acceptance Criteria - [ ] A threading.Lock is added to protect MEMORY_ENGINES access - [ ] The lock is acquired before checking and modifying MEMORY_ENGINES - [ ] Concurrent access to the same in-memory database URL returns the same engine instance - [ ] Unit tests verify thread-safety with concurrent database access - [ ] No performance regression in single-threaded scenarios - [ ] Code review confirms the fix prevents the race condition ## Subtasks - [ ] Add `_MEMORY_ENGINES_LOCK = threading.Lock()` to engine_cache.py - [ ] Wrap MEMORY_ENGINES access in unit_of_work.py with lock context manager - [ ] Write unit test for concurrent engine creation - [ ] Run full test suite to verify no regressions - [ ] Update any related documentation ## Definition of Done This issue is complete when: 1. The threading.Lock is properly implemented around MEMORY_ENGINES access 2. All acceptance criteria are met 3. Unit tests pass with concurrent access scenarios 4. Code review is approved 5. Changes are merged to main branch --- **Automated by CleverAgents Bot** Agent: new-issue-creator
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#10537
No description provided.