Severity: Low · Area: Tests / quality · Category: test-coverage
Location: services/agent/selene_agent/utils/session_pool.py:160
What's wrong
Pool tests drive idle_sweep, _flush_one, and _hydrate_from_db directly, but the public entry point get_or_create (session_pool.py:160-199) — session minting, hydrate-on-miss, recency bump, and the at-capacity LRU eviction that flushes the dropped session (lines 193-199) — has no coverage. This is the concurrency-sensitive path every /api/chat and /ws/chat request goes through.
How it fails
A change to the eviction condition (e.g. >= vs > on max_size, or evicting before checking session_id in self._sessions) silently drops or double-flushes an active session under load; the suite passes because only the private helpers are tested.
Suggested fix
Add tests that fill a max_size=2 pool via get_or_create, assert the LRU session is flushed (reason=lru_eviction) and removed, the requested session survives, and that concurrent get_or_create for the same new sid yields one orchestrator.
Adversarial verification — both skeptics confirmed
Skeptic 1 (confirmed) — Confirmed. get_or_create (session_pool.py:160) and the LRU-eviction block in _admit (lines 193-199) have zero test coverage: test_session_pool_timeout.py and test_pool_sweep_size.py insert orchestrators directly into pool._sessions and drive idle_sweep/_flush_one/_hydrate_from_db as private helpers; test_resume_endpoint.py mocks pool.get…
Skeptic 2 (confirmed) — Confirmed. get_or_create (session_pool.py:160-186) and the LRU-eviction block in _admit (lines 193-199) have no test coverage: test_session_pool_timeout.py and test_pool_sweep_size.py insert orchestrators directly into pool._sessions and drive idle_sweep/_flush_one/_hydrate_from_db as private helpers (test_pool_sweep_size.py:172 even pas…
Filed from a multi-agent audit of 855f5cc: 16 reviewers over ~42k lines produced 170 raw findings; each was handed to 2 independent agents prompted to refute it, and only findings both confirmed were kept (19 refuted, 10 split-verdict, 127 unique confirmed). Line numbers are 1-indexed against 855f5cc and will drift as the code changes.
Severity: Low · Area: Tests / quality · Category:
test-coverageLocation:
services/agent/selene_agent/utils/session_pool.py:160What's wrong
Pool tests drive idle_sweep, _flush_one, and _hydrate_from_db directly, but the public entry point get_or_create (session_pool.py:160-199) — session minting, hydrate-on-miss, recency bump, and the at-capacity LRU eviction that flushes the dropped session (lines 193-199) — has no coverage. This is the concurrency-sensitive path every /api/chat and /ws/chat request goes through.
How it fails
A change to the eviction condition (e.g.
>=vs>on max_size, or evicting before checkingsession_id in self._sessions) silently drops or double-flushes an active session under load; the suite passes because only the private helpers are tested.Suggested fix
Add tests that fill a max_size=2 pool via get_or_create, assert the LRU session is flushed (reason=lru_eviction) and removed, the requested session survives, and that concurrent get_or_create for the same new sid yields one orchestrator.
Adversarial verification — both skeptics confirmed
Filed from a multi-agent audit of
855f5cc: 16 reviewers over ~42k lines produced 170 raw findings; each was handed to 2 independent agents prompted to refute it, and only findings both confirmed were kept (19 refuted, 10 split-verdict, 127 unique confirmed). Line numbers are 1-indexed against855f5ccand will drift as the code changes.