ENG-3492: Fix identity verification for duplicate privacy requests

[JadeCara]

Ticket ENG-3492

Description Of Changes

When duplicate detection is enabled, a privacy request can be marked as duplicate before the user completes identity verification (via the privacy center flow). Previously, verify_identity only accepted identity_unverified status, so it rejected duplicate requests with a 400 error — blocking the user from completing verification.

This fix allows verify_identity to also accept duplicate status. The request transitions to pending so that handle_approval can re-evaluate duplicate detection with the fresh identity_verified_at timestamp. This matters because the first-verified request in a duplicate group should become canonical — the duplicate detection logic in verified_identity_cases uses identity_verified_at ordering to determine which request wins.

Code Changes

• src/fides/api/models/privacy_request/privacy_request.py — verify_identity now accepts duplicate in addition to identity_unverified status, always transitions to pending
• tests/.../test_privacy_request_endpoints.py — Added test_verify_identity_duplicate_request to confirm duplicate requests can successfully verify

Steps to Confirm — Verified Locally

1. Enable duplicate request detection, identity verification, and manual approval in settings
2. Configure Mailgun messaging service
3. Submit a DSR from the privacy center with an email address → status: identity_unverified
4. Submit another DSR with the same email → status: duplicate
5. Verify identity on the duplicate (second) request → succeeds, transitions to pending, becomes canonical
6. First request is re-evaluated and flipped to duplicate
7. Verify identity on the first request (now duplicate) → succeeds, stays duplicate (second to verify)

E2E results:

Request 1 (pri_cdacd...): identity_unverified → duplicate (after R2 verified first) → verified, stays duplicate
Request 2 (pri_6802f...): duplicate → pending (first verified, became canonical)

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ignored	Preview	Apr 21, 2026 5:03pm
fides-privacy-center	Ignored		Apr 21, 2026 5:03pm

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.94%. Comparing base (b5b98e6) to head (f9bc844).
⚠️ Report is 10 commits behind head on main.

❌ Your project status has failed because the head coverage (84.94%) is below the target coverage (85.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7971      +/-   ##
==========================================
- Coverage   85.04%   84.94%   -0.10%     
==========================================
  Files         631      630       -1     
  Lines       41213    41082     -131     
  Branches     4807     4768      -39     
==========================================
- Hits        35049    34899     -150     
- Misses       5070     5101      +31     
+ Partials     1094     1082      -12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[JadeCara]

/code-review

[claude]

Code Review: Fix duplicate request identity verification

The fix is targeted, minimal, and logically correct. Here's a summary of the analysis.

What the change does

Previously, verify_identity only allowed the identity_unverified status. Any request already marked duplicate would throw IdentityVerificationException, blocking the user from completing verification. The fix adds duplicate to the allowed set so those requests can transition to pending. The endpoint then calls handle_approval → check_for_duplicates → is_duplicate_request, which re-evaluates the request with the fresh identity_verified_at timestamp, potentially promoting it to canonical.

Logic correctness

The re-evaluation path is sound:

• After verify_identity, status is pending (not duplicate), so the early-return at duplication_detection.py:398 (if request.status == PrivacyRequestStatus.duplicate: return True) does not trigger.
• verified_identity_cases correctly picks the request with the earliest identity_verified_at as canonical and re-marks the rest as duplicate. The docstring claim about "first-verified becomes canonical" is accurate.
• The verification code is single-use and TTL-bound, so no infinite duplicate → pending → duplicate loop is possible.

Findings

Three comments are inline; summarized here:

1. Missing assertions in the new test — mock_dispatch_message and mock_run_privacy_request are patched but never asserted. The test doesn't confirm whether a receipt email was sent or whether the request was queued.

2. No test for the "stays duplicate" case — only the happy path (duplicate becomes canonical) is tested. The inverse case — duplicate verifies after the canonical already verified, so it should be re-marked as duplicate — is not covered.

3. Receipt email sent before re-evaluation (pre-existing, low severity) — send_privacy_request_receipt fires before handle_approval re-checks duplication, so in the inverse case above, a receipt email is sent for a request that ends up back in duplicate. Not introduced by this PR, but the fix expands the cases where this can happen.

Summary

The core model change is correct and the changelog entry is present. The main gap is test coverage for the duplicate → pending → duplicate cycle. The happy-path fix is ready; the test improvements are recommended before merging.

🔬 Codegraph: connected (47107 nodes)

💡 Write /code-review in a comment to re-run this review.

[erosselli]

approved with a question!

[erosselli]

if we mark it as pending, is there any other way to flag to the admins that "this might be a duplicate " ?

[JadeCara]

It checks when it re-queues and will get marked as a duplicate or if it is the first verified DSR it will get processed as usual and the unverified DSR will get marked as duplicate instead. Tested both paths manually.