Aglet

Verify Duplicate Prevention and Record Counts

Duplicate verification must test both deduplication and preservation. Exercise retries, reordered delivery, changed revisions, and legitimate repeats, then compare stored cardinality and business outputs. Confirm the chosen identity key is stable across the boundaries that create and consume the record.

Check whether the outcome improved

  1. Exercise delivery cases

    Run a bounded fixture through first delivery, exact retry, delayed retry, reordered delivery, and a legitimate second event. Include a changed payload revision if versions are supported by the contract. Assert the expected stored representation and explain every retained or rejected row.

  2. Compare output integrity

    Measure raw row count, logical record count, latest-state selection, aggregates, joins, and exports before and after the prevention or correction. Inspect changed identifiers and conflicting fields. Confirm totals move for the intended cohort without hiding a legitimate event or unrelated source.

  3. Check operational boundaries

    Verify the identity key survives parsing, storage, retry handling, and downstream reads with documented types and limits. Confirm an ambiguous or missing key receives a visible outcome. Retain fixtures, ordering assumptions, and query outputs so another engineer can repeat the check.

What to carry forward

Accept the change when retries follow the identity rule, legitimate repeated events remain visible, changed revisions behave as documented, and every output difference is explained. Keep the gate open for sources with weaker keys or untested ordering. State exactly which duplicate classes and time windows were covered.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow