Proxy Duplicate Detection Service
Component Detail
Description
Detects conflicting activity entries by querying all registrations matching the triple (peer mentor ID, date, activity type) regardless of which coordinator submitted them. Surfaces conflict metadata for coordinator decision.
proxy-duplicate-detection-service
Summaries
Duplicate activity registrations represent a direct financial risk: overpayments, inflated reporting metrics, and audit failures that erode trust with program stakeholders. The Proxy Duplicate Detection Service acts as an automated safeguard, intercepting conflicting entries before they reach the database regardless of which coordinator submitted the original record. By surfacing conflict metadata instantly, coordinators can resolve discrepancies in real time rather than discovering them weeks later during reconciliation. This protects program integrity, reduces manual correction overhead, and ensures funding bodies receive accurate participation data — directly reducing the risk of clawbacks or compliance penalties.
This service is a shared component consumed by both individual proxy registration and bulk registration flows, making it a blocking dependency for both features. Its medium complexity stems from the composite-key query logic and the need to correctly exclude soft-deleted or voided records from conflict checks. Batch-mode duplicate checking must be performance-tested against realistic coordinator workloads — a coordinator registering 30 participants simultaneously should not experience noticeable latency. Integration tests must cover edge cases: same mentor, same date, different activity type (no conflict); and records voided after submission (must not be flagged).
Plan two to three days for implementation plus one day for integration testing with the bulk registration flow.
This service wraps the proxy-activity-repository's findDuplicate and findBatchDuplicates queries, adding a semantic layer that translates raw DB results into structured DuplicateConflict models. The composite key is (mentor_id, date, activity_type_id) — all three must match for a conflict. The isDuplicate method returns a boolean for lightweight pre-submission checks; checkDuplicate returns the full conflict metadata including original submitter ID and timestamp. Voided/soft-deleted records must be filtered at the query level to avoid false positives.
Batch mode should use a single DB round-trip (IN clause or batch query), not N individual calls. Runs in both mobile (via Supabase client) and backend contexts — ensure the repository abstraction handles both execution environments transparently.
Responsibilities
- Query existing records by mentor ID + date + activity type composite key
- Return conflict details including the original submitter and timestamp
- Support single-record and batch-mode conflict checks
- Ignore soft-deleted or voided records in conflict checks
Interfaces
checkDuplicate(String mentorId, DateTime date, String activityTypeId)
checkBatchDuplicates(List<DuplicateCheckRequest> requests)
getDuplicateDetails(String activityId)
isDuplicate(String mentorId, DateTime date, String activityTypeId)
Relationships
Dependents (2)
Components that depend on this component
Related Data Entities (2)
Data entities managed by this component