[TochukwuJustice]

closes #683

Summary of Changes

• Live Preview Counts (previewErasure): Replaced hardcoded zero values in preservedRecords with live counts querying:
  • adminAuditLogs: Matches logs where target = userId or details.userId = userId via an indexed OR clause.
  • referralConversionsAsOwner: Counts conversions associated with referral codes owned by userId (referralCode.ownerUserId).
  • referralConversionsAsReferred: Counts conversions where the user was the referred party (referredUserId = userId).
• Pre-Deletion Snapshot in executeErasure: Relocated preserved-record counting before tx.user.delete(...) inside the transaction. This prevents PostgreSQL cascade deletion on ReferralCode and ReferralConversion from removing records prior to aggregation, ensuring execution metrics match dry-run preview metrics.
• Removed Stubbing: Replaced Promise.resolve(0) stubs in executeErasure with real counting queries.
• Test Coverage:
  • Updated tests/unit/compliance/privacyErasure.test.ts with mocks and assertions verifying exact preservedRecords counts and query parameters for preview and execution.
  • Added referralConversion mock to tests/integration/privacy-erasure.integration.test.ts to ensure lifecycle tests pass.

Reason for the Changes

Issue #683: When compliance operators inspect erasure impact via POST /api/admin/erasure/requests/:id/preview (or execution dry runs), previewErasure returned hardcoded zeroes for preserved records (adminAuditLogs, referralConversionsAsOwner, referralConversionsAsReferred), and executeErasure used Promise.resolve(0) stubs for referral metrics. This produced systematically inaccurate impact assessments prior to approving irreversible deletion.

[drips-wave]

@TochukwuJustice Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits