agent's dedup merge ran on replayed webhooks - the same candidate got merged twice and the winning record lost its...

TL;DR: Dedupe webhook events by event id before processing, and make merges union fields instead of overwriting them. The replay ran the merge a second time, the second run picked the other record as the winner, and its empty notes overwrote the real ones. Idempotent intake plus non-destructive merge fixes both halves.

agent's dedup merge ran on replayed webhooks  -  the same candidate got merged twice and the winning record lost its interview notes

1. Check the webhook processor for event-id deduplication.

Expected: none exists; the same event payload processes fully every time it arrives.

1. Store processed event ids and skip repeats before any merge logic runs.

Expected: replaying the same webhook becomes a no-op.

1. Change the merge to union fields: keep notes, attachments, and history from both records instead of last-write-wins.

Expected: a test merge of two records preserves the interview notes from the loser.

1. Recover the lost notes from the ATS audit log or from a pre-merge snapshot if one was kept.

Expected: the interview notes are restored to the surviving record.

1. Add a merge audit trail recording which records merged, when, and which fields won.

Expected: every merge leaves a trace a human can review and reverse.

Use this when

• Duplicate or replayed webhooks trigger the same mutation twice.
• Merges overwrite data instead of combining it.
• Records lose notes, attachments, or history after dedup runs.

Not for this skill when

• The duplicates are genuinely different people merged by a bad matching rule (fix the matcher, not the idempotency).
• The data loss came from a manual merge in the ATS UI.
• The webhook fired once and the merge logic itself is wrong.

Variant phrasings

• replayed webhook merged the same candidate twice
• dedup merge overwrote interview notes
• winning record lost its notes after a second merge
• webhook redelivery re-ran the candidate merge

Why it happens

Webhooks redeliver by design: retries, replays, and at-least-once delivery are normal. The merge handler was written as if each event arrives exactly once, so the replay executed the merge logic a second time. The second run re-evaluated the winner from already-merged state, picked the other record, and its blank fields overwrote populated ones. Exactly-once processing has to be built at the intake; the merge itself has to be safe to run twice.

Edge cases

• True duplicates arriving close together that are not replays: dedupe by event id does not catch these. That is the matcher's job; keep the two mechanisms separate.
• Merges of more than two records: union across all of them, and record every source.
• Notes edited during the merge window: a human editing the loser mid-merge can still lose work. Lock the records during the merge or re-check after.
• The losing record held the only copy of an attachment: union must cover attachments and files, not just text fields.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iUNA256sE2cSq4EGJCoXzA