src/main/java/com/semosan/api/domain/tracking/scheduler/TrackingSessionExpiryScheduler.java (1)

23-23: TODO: Configurable expiry threshold and notification policy.

The TODO suggests externalizing the 24-hour threshold to a property and considering user notifications on expiration.

Would you like me to draft a configuration class with @ConfigurationProperties for the expiry duration and outline a notification hook point in the expiration loop?

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/semosan/api/domain/tracking/scheduler/TrackingSessionExpiryScheduler.java`
at line 23, Replace the hardcoded 24h expiry with a configurable property:
create an `@ConfigurationProperties` class (e.g., ExpiryProperties) exposing a
java.time.Duration field (property key like tracking.session.expiry) and
register it as a bean; inject ExpiryProperties into
TrackingSessionExpiryScheduler and use its Duration instead of the literal 24
hours in the expiration loop (e.g., in the method that checks session
age/expireSessions()). Also add a nullable/optional NotificationService hook
(interface name NotificationService) and call it when a session is expired
(guarded by a new config flag in ExpiryProperties, e.g., notifyOnExpire) so
notification behavior can be toggled without changing code.

src/main/java/com/semosan/api/domain/tracking/service/TrackingSessionService.java (2)

78-79: TODO: HikingRecord creation integration.

The TODO references issue #20 for integrating Redis Stream GPS points and creating HikingRecord/HikingMember entities.

Would you like me to open a tracking issue or provide a skeleton implementation outline for the GPS aggregation and record persistence logic?

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/semosan/api/domain/tracking/service/TrackingSessionService.java`
around lines 78 - 79, The TODO in TrackingSessionService needs implementation to
aggregate Redis Stream GPS points and create HikingRecord/HikingMember entities
when a session ends: add a method (e.g., createHikingRecordFromSession or
finalizeSessionAndCreateHikingRecord) inside TrackingSessionService that (1)
reads GPS entries from the Redis Stream for the session (use a Redis stream
client/consumer to fetch by session key), (2) aggregates and computes statistics
(distance, duration, elevation, bounding box, sample count), (3) constructs
HikingRecord and associated HikingMember entities and persists them via the
existing repositories within a transactional boundary, and (4) mark the tracking
session closed and ensure idempotency and error handling (retries/logging) so
repeated calls don't create duplicates. Ensure the new method is invoked at the
normal-termination path currently closing only state/time so the Redis
aggregation + persistence happens as part of session termination.

---

29-30: ⚡ Quick win

Extract duplicated ACTIVE_STATES constant to a shared location.

ACTIVE_STATES is defined identically here and in TrackingSessionExpiryScheduler (line 30-31). If the set of active states changes, both locations must be updated, risking inconsistency.

Consider defining this constant once in TrackingSessionStatus enum or a dedicated constants class, then referencing it from both service and scheduler.

♻️ Example: Define in enum

In TrackingSessionStatus:

public enum TrackingSessionStatus {
    IN_PROGRESS, PAUSED, COMPLETED, ABANDONED;
    
    public static final Set<TrackingSessionStatus> ACTIVE_STATES = 
        EnumSet.of(IN_PROGRESS, PAUSED);
}

Then use TrackingSessionStatus.ACTIVE_STATES in both service and scheduler.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/semosan/api/domain/tracking/service/TrackingSessionService.java`
around lines 29 - 30, Duplicate ACTIVE_STATES should be centralized: remove the
EnumSet constant from TrackingSessionService and TrackingSessionExpiryScheduler
and define a single public constant on the TrackingSessionStatus enum (e.g.,
TrackingSessionStatus.ACTIVE_STATES) or in a dedicated constants class, then
update both TrackingSessionService and TrackingSessionExpiryScheduler to
reference that single symbol (TrackingSessionStatus.ACTIVE_STATES) so the
active-state definition lives in one place.

src/main/java/com/semosan/api/domain/tracking/repository/TrackingSessionRepository.java (1)

29-37: Add a composite index for scheduler query path.

For hourly scans on active states + cutoff, add an index like (status, started_at) (or (status, updated_at) if you keep current semantics) to avoid table-scan growth.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/semosan/api/domain/tracking/repository/TrackingSessionRepository.java`
around lines 29 - 37, The scheduler query in TrackingSessionRepository
(findStaleActiveSessions) will table-scan as the table grows; add a composite DB
index on (status, updated_at) or (status, started_at) depending on your
semantics to support the WHERE ts.status IN :statuses AND ts.updatedAt < :cutoff
path. Update the TrackingSession entity mapping (or a migration) to create the
composite index on the status and timestamp column used by this query so the
database can use the index for efficient hourly scans.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes