Duplicate Queue Repository
Component Detail
Description
Repository that provides coordinator-scoped queries for activities where duplicate_reviewed is false and a matching sibling record exists. Encapsulates the Supabase filter logic and pagination so the queue service remains independent of query construction details.
duplicate-queue-repository
Summaries
The Duplicate Queue Repository is the data access backbone of the coordinator deduplication workflow. It ensures coordinators can see exactly which activity records in their chapter require attention due to duplicate flags, and provides the write operations needed to mark those records as resolved. Without accurate, scoped queries at this layer, coordinators could be presented with incorrect or cross-chapter data, undermining both program governance and data privacy. By encapsulating complex filter logic — including sibling record existence checks — this repository keeps the queue experience reliable and consistent, enabling coordinators to maintain clean activity records and produce accurate reports without manual database intervention.
The Duplicate Queue Repository is a medium-complexity data layer component with no custom component dependencies, interfacing directly with Supabase. It must be delivered before the Deduplication Queue Service can be completed and tested. Key complexity areas include coordinator-scoped chapter filtering, sibling record existence checks (same peer mentor, type, and date), paginated result sets with accurate total counts, and concurrent write safety for markResolved(). The pagination implementation requires agreement on page size defaults and response shape early in the sprint.
Integration testing should validate that cross-chapter data is never returned and that count accuracy holds after concurrent resolution actions. The total count used for badge display must remain consistent with paginated results to avoid UI discrepancies.
The Duplicate Queue Repository provides four interfaces: fetchUnresolvedByCoordinator() with pagination parameters, countUnresolved() for badge count, markResolved() with resolution metadata, and fetchSiblingRecords() for sibling existence lookup. All queries filter on duplicate_reviewed = false and must be scoped to chapters associated with the given coordinatorId — this scoping must be enforced at the Supabase query level, not in the calling service. The sibling check queries for activities matching the same peer_mentor_id, activity_type_id, and date triple, returning matches for UI display. markResolved() updates both duplicate_reviewed and resolution_notes fields atomically.
Pagination must return both the current page data and a total count in a single response object. Supabase row-level security policies should be validated against this repository's queries to ensure scoping is enforced at the database level as well as the application level.
Responsibilities
- Query activities with duplicate_reviewed = false filtered to coordinator's chapters
- Perform existence check for matching sibling records (same peer mentor, type, date)
- Update duplicate_reviewed and resolution_notes fields for coordinator actions
- Return paginated result sets with total count for badge display
Interfaces
fetchUnresolvedByCoordinator(coordinatorId, page, pageSize)
countUnresolved(coordinatorId)
markResolved(activityId, resolvedBy, notes)
fetchSiblingRecords(peerId, activityTypeId, date)