ProxyDuplicateDetector: structured per-mentor warning output
epic-bulk-and-proxy-registration-services-task-012 — Implement the result formatter in ProxyDuplicateDetector that maps raw duplicate query results into a List<MentorDuplicateWarning>. Each warning must include: mentorId, mentorName, conflicting activity date, conflicting activity type, the ID of the existing record, and the coordinator who originally recorded it (for NHF multi-coordinator chapters). Return an empty list when no duplicates are found so callers can proceed without branching.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Keep this method as a pure transformation — no side effects, no I/O. If mentorName is not available in the raw query result (because the activities table stores only mentorId), resolve names from a Map
For the conflictingDate field, store as a Dart DateTime (UTC midnight) for consistency with the rest of the app's date handling — parse from the Supabase ISO 8601 string in this formatter.
Testing Requirements
Since formatWarnings is a pure function, unit tests require no mocks. Test directly with constructed DuplicateQueryResult and MentorActivityCandidate lists. Test cases (covered in task-013): exact full mapping, missing optional fields skipped gracefully, empty input returns empty list, NHF cross-coordinator field populated correctly. Use expect() with equals() on freezed MentorDuplicateWarning objects to verify structural equality.
The Proxy Registration Service must verify that the coordinator has a legitimate assignment relationship with the target peer mentor before creating a record. If this check is implemented only in application code and not enforced at the DB/RLS level, a compromised or buggy client could bypass it by calling the Supabase endpoint directly, creating fraudulent proxy records for arbitrary peer mentors.
Mitigation & Contingency
Mitigation: Implement permission validation at two levels: (1) application-layer check in Proxy Registration Service that queries the assignments table before constructing the payload, and (2) RLS policy on the activities table that restricts INSERT to rows where recorded_by_user_id matches the authenticated user AND peer_mentor_id is in the set of peer mentors assigned to that coordinator. The RLS policy is the authoritative guard; the service-layer check provides early user-facing feedback.
Contingency: If RLS policy implementation is blocked by Supabase plan constraints, implement a Supabase Edge Function as a proxy endpoint that enforces the permission check server-side before forwarding to the DB. Disable direct client inserts entirely for proxy activities.
For a bulk session with 30 selected peer mentors, the Proxy Duplicate Detector must query existing activities for each mentor. If implemented as 30 sequential Supabase queries, round-trip latency could make the bulk confirmation screen feel slow (>3s), degrading coordinator experience and potentially causing timeouts.
Mitigation & Contingency
Mitigation: Implement the duplicate check as a single Supabase query using an IN clause on peer_mentor_id combined with the activity_type and date filters, returning all potential duplicates for the entire batch in one network round-trip. Group results client-side by mentor ID to produce the per-mentor warning structure.
Contingency: If the single-query approach returns too much data for very large chapters, add a database index on (peer_mentor_id, activity_type, date) and profile query time. If still insufficient, accept a short loading state on the confirmation screen with a progress indicator rather than pre-loading duplicates before navigation.