Duplicate Resolution Handler
Component Detail
Description
Orchestrates the three resolution paths available to a user when a duplicate is detected: proceed (insert with duplicate_reviewed: true), merge (update the existing record with any corrections and cancel the new submission), or cancel (discard the current draft). Ensures the activity wizard resumes or exits correctly after each path.
duplicate-resolution-handler
Summaries
The Duplicate Resolution Handler directly protects data quality by giving users clear, actionable choices when a potential duplicate activity is detected before it enters the system. Rather than silently allowing duplicate records that inflate reporting metrics or corrupt peer mentor activity histories, this component presents three governed outcomes: proceed with an audit flag, merge corrections into the existing record, or cancel the submission entirely. Clean activity data is foundational to accurate program reporting, coordinator oversight, and funding compliance. By resolving ambiguity at the point of entry rather than during costly post-hoc data cleanup, this component reduces administrative overhead and supports trust in the platform's reporting accuracy across all chapters.
The Duplicate Resolution Handler is a medium-complexity frontend and mobile component that sits at the intersection of user flow and data integrity. It depends on both the Duplicate Check Repository and the Duplicate Detection Service, meaning those two components must be stable and tested before this handler can be fully integrated and verified. The three resolution paths — proceed, merge, and cancel — each require dedicated UI states and end-to-end test coverage, including edge cases around wizard resumption and exit behaviour. QA should plan for regression testing whenever the activity submission wizard is modified, since this handler governs critical post-detection branching.
Analytics integration for the resolution outcome event also requires coordination with the reporting team.
The Duplicate Resolution Handler implements the controller layer for post-detection user decisions in the activity submission flow. It exposes four interfaces: handleProceed(), handleMerge(), handleCancel(), and getResolutionOutcome(). The proceed path delegates to the Duplicate Check Repository's insertWithReviewedFlag() to persist the activity with duplicate_reviewed: true. The merge path calls updateExistingRecord() on the existing activity ID using corrected fields from the draft.
The cancel path discards the draft and restores the wizard to its previous state. The component emits a resolution outcome event consumed by analytics and audit trail systems. It depends on both duplicate-check-repository and duplicate-detection-service, so those must be initialized before this handler is mounted. No local state is persisted; all writes are delegated to the repository layer.
Responsibilities
- Handle 'proceed' path by inserting activity with duplicate_reviewed flag set to true
- Handle 'merge' path by updating the existing record and discarding the draft
- Handle 'cancel' path by returning user to the activity wizard without saving
- Emit resolution outcome event for analytics and audit trail
Interfaces
handleProceed(draftActivity)
handleMerge(existingActivityId, draftActivity)
handleCancel()
getResolutionOutcome()
Relationships
Dependencies (2)
Components this component depends on