Skip to content

POTACAT: use stable external identities for replay-safe imports #537

Description

@rtreit

Parent: #529

Summary

Add a generic external-QSO identity mechanism to the import pipeline, using POTACAT's APP_POTACAT_UUID as the first fully tested producer identity.

Identity model

  • Keep QsoRecord.local_id as the local primary identity.
  • Represent external identity as a bounded producer namespace plus value, or an equivalent domain structure that can support more than one producer without hard-coding POTACAT throughout the engine.
  • Map APP_POTACAT_UUID into the external identity mechanism while preserving lossless ADIF export.
  • Enforce uniqueness for active records where the storage model permits it.

Matching order

  1. Exact external identity.
  2. Existing explicit import fingerprint rules.
  3. Existing fuzzy ADIF duplicate matching.

Replay and update behavior

  • An exact replay must not create a second QSO.
  • A resend with changed import-refreshable fields follows the engine's documented UDP refresh policy.
  • A resend must not overwrite newer unrelated local edits outside that policy.
  • A soft-deleted QSO must not be silently resurrected.
  • Identity collisions with materially different core QSO data must produce a safe diagnostic rather than merging blindly.
  • Restart and engine switching must preserve identity matching.

Implementation scope

  • Shared domain/proto changes if required.
  • Memory and SQLite indexes/storage in both engines.
  • ADIF mapping and import pipeline changes.
  • Engine specification and repair/migration behavior.

Tests

  • Exact replay before and after restart.
  • Changed-field resend.
  • Locally edited record before resend.
  • Soft-deleted record before resend.
  • Conflicting records with the same external identity.
  • Rust/.NET and memory/SQLite parity.

Acceptance criteria

  • Explicit POTACAT resend is safe and idempotent.
  • Identity matching remains generic enough for other ADIF producers.
  • Local identity and edit history remain authoritative.
  • Both engines implement the same merge and failure policy.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions