fix: eliminate N+1 queries in _load_candidate_sessions event_type filter

[acailic]

Summary

Fixes #132.

• Replaces the Python loop in storage/search.py:_load_candidate_sessions that issued one SELECT … LIMIT 1 query per candidate session when an event_type filter was active
• Uses a single SQL IN subquery instead, pushing the filter into the initial session SELECT and reducing query count from O(n sessions) to O(1)

Root cause

# before: N separate round-trips
for session in sessions:
    event_stmt = select(EventModel).where(
        EventModel.session_id == session.id, ...
    ).limit(1)
    event_result = await self.session.execute(event_stmt)
    ...

With 100 candidate sessions this issued 101 SQL queries; with 1000 it issued 1001.

Fix

# after: 0 extra round-trips — pushed into the main SELECT
event_subq = (
    select(EventModel.session_id)
    .where(EventModel.tenant_id == self.tenant_id,
           EventModel.event_type == event_type_str)
    .distinct()
    .scalar_subquery()
)
stmt = stmt.where(SessionModel.id.in_(event_subq))

Test plan

• ruff check storage/search.py — no issues
• pytest tests/test_search_routes.py tests/test_collector_baseline.py — 72 passed

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR addresses #132 by removing an N+1 query pattern in SessionSearchService._load_candidate_sessions when applying an event_type filter, pushing the filter into SQL to keep query count constant.

Changes:

• Replaced per-session event probing queries with a single IN (SELECT …) subquery filter.
• Moved the session query execution to after all filters (including event_type) are applied.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

DISTINCT in the event_type subquery is unnecessary for correctness (duplicates in an IN (SELECT …) don’t change results) and may add avoidable sort/hash work on large event tables. Consider dropping .distinct() or switching to a correlated EXISTS predicate, which often plans better and avoids materializing a distinct set.

Suggested change

.distinct()

[acailic]

Dropped .distinct() from the subquery — agreed it is unnecessary for IN(SELECT ...) correctness and adds avoidable overhead on large event tables. Fixed in 51549ab.

[Copilot]

There are existing unit tests for _load_candidate_sessions (e.g., status filtering), but this change significantly alters the event_type filtering behavior by pushing it into SQL. Please add a test that asserts the generated query includes the event_type predicate (or, preferably, an integration-style test that verifies sessions without matching events are excluded).

[acailic]

Added two unit tests for _load_candidate_sessions with event_type filter in 51549ab: test_load_candidate_sessions_event_type_filter_in_sql asserts exactly one DB query is issued and that events.event_type appears in the WHERE clause (confirming the predicate is in SQL, not a Python loop); test_load_candidate_sessions_event_type_excludes_non_matching_sessions asserts that when the DB returns no rows the result is empty and still only one query was issued.