test(signals): Expand Activity Signals Test Coverage and Time-Range Query Support

[yayyyyshi]

Summary

This PR expands the automated integration test coverage for the Activity Signals module and enhances the querying API with timestamp range filtering.

The changes improve validation, authentication testing, filtering behaviour, pagination coverage, logging verification through mocking, and timestamp-based querying, providing stronger confidence in the Activity Signals API before Phase 4 Recommendation Engine integration.

---

What Changed — File by File

tests/test_activity_signals.py

Expanded the Activity Signals integration test suite.

Signal Ingestion Tests

Added coverage for:

• Successful signal ingestion
• Explicit source preservation
• Default source="api" behaviour
• Authentication required (401)
• Multiple stream ingestion
• Missing stream
• Missing event_type
• Invalid payload type
• Empty payload handling
• Client timestamp ignored by server
• Timestamp automatically generated
• Timestamp not required
• Valid signal persistence

Query Endpoint Tests

Added coverage for:

• Empty signal list
• Listing all signals
• Retrieve signal by ID
• Non-existent signal returns 404
• Stream filtering
• Source filtering
• Event type filtering
• Timestamp range filtering
• Pagination using limit

Logging Tests

Added mock-based tests verifying:

• log_user_activity() is called during signal ingestion.
• Signal ingestion still succeeds if activity logging raises an exception.

These tests improve confidence around both the normal execution path and failure scenarios without requiring changes to the production logging implementation.

---

src/lpi/routers/signals.py

Extended the Activity Signals query endpoint.

Added

New optional query parameters:

• start
• end

These allow clients to retrieve signals within a specified timestamp range.

Example:

GET /api/v1/signals/?start=2026-06-01T00:00:00Z&end=2026-06-30T23:59:59Z

Updated

• Passes start and end filters to the store layer.
• Preserves existing authentication, pagination, and filtering behaviour.
• Updates endpoint documentation to describe timestamp filtering.

---

src/lpi/store.py

Extended the Supabase-backed query layer.

Added

Support for timestamp range filtering using Postgres comparison operators:

• .gte("timestamp", start.isoformat())
• .lte("timestamp", end.isoformat())

The store now supports filtering by:

• user
• stream
• event type
• source
• timestamp range
• pagination

All filtering continues to execute server-side in Supabase/Postgres.

---

Test Coverage

The Activity Signals module is now covered for:

Feature	Status
Signal ingestion	✅
Authentication	✅
Validation errors	✅
Multiple streams	✅
Default source handling	✅
Explicit source handling	✅
Server-generated timestamp	✅
Timestamp optional in requests	✅
Empty payload handling	✅
Get signal by ID	✅
Non-existent signal	✅
Stream filtering	✅
Source filtering	✅
Event type filtering	✅
Timestamp range filtering	✅
Pagination (limit)	✅
Logging success path	✅
Logging failure path	✅

---

Notes for Reviewers

• Timestamp filtering (start and end) is implemented end-to-end from the API layer through the Supabase query builder.
• Logging behaviour is verified using mocks, since log_user_activity() has no observable external side effects.
• Existing endpoint behaviour remains unchanged for clients that do not provide timestamp filters.
• All new tests follow the existing integration testing pattern using the local Supabase instance.

---

How to Test

# Start local Supabase
supabase start

# Apply migrations
supabase db push

# Run Activity Signals tests
pytest tests/test_activity_signals.py -v

Example timestamp filtering:

GET /api/v1/signals/?start=2026-06-01T00:00:00Z&end=2026-06-30T23:59:59Z

Example pagination:

GET /api/v1/signals/?limit=20

---

Impact

This PR strengthens the Activity Signals module by:

• expanding automated integration test coverage,
• improving API validation coverage,
• verifying authentication behaviour,
• validating logging behaviour through mocking,
• introducing timestamp-based querying,
• and improving confidence in the module ahead of Phase 4 Recommendation Engine development.

---

Phase

Module: Activity Signals

Phase: 3

---

Owner

Yashika Verma