agent's dedup merge ran on replayed webhooks — the same can

Not specified by the original author.

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.

2. Store processed event ids and skip repeats before any merge logic runs. Expected: replaying the same webhook becomes a no-op.

3. 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.

4. 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.

5. 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

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

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

TL;DR:

Not specified by the original author.

TL;DR

List existing webhooks before registering and skip when the callback URL and event set already exist. Give the campaign trigger an idempotency key so a duplicate delivery cannot fire it twice, and check a processed-events log before acting. Duplicate registrations and redeliveries become harmless.

loops.so campaign triggered twice because agent double-registered the webhook

Use this when

• a campaign or automation fires twice for one event
• webhook listings show duplicate registrations
• the agent registers webhooks on every deploy or restart
• providers redeliver events and the handler is not idempotent

Not for this skill when

• the campaign logic itself sends duplicates
• the audience list contains the same contact twice
• you need help writing the campaign content

Steps

1. Before registering a webhook, list existing webhooks and skip registration if the URL and event set already exist. Expected: registration is idempotent across deploys and restarts.
2. Dedupe on the normalized callback URL plus event types, not on the registration response. Expected: double-clicks and retries do not create twins.
3. Give the campaign trigger an idempotency key (campaign id plus run id) so a duplicate webhook delivery cannot fire it twice. Expected: duplicate deliveries are harmless.
4. On receiving a webhook event, check a processed-events log before acting. Expected: redeliveries are acknowledged and ignored.
5. After cleanup, delete the duplicate registration and verify only one remains. Expected: the webhook list shows a single entry.

Variant phrasings

campaign fired twice from a duplicate webhook

Short version: list before registering and dedupe on URL plus events.

agent registered the webhook twice

Short version: make registration idempotent so restarts cannot create twins.

webhook redelivery triggered the campaign again

Short version: key the trigger idempotently and keep a processed-events log.

Compatibility: applies to Loops and any webhook provider with a list endpoint; the pattern is provider-agnostic, no SDK version pinned.

Why it happens

The agent registered the webhook on every run without checking what already existed, so two identical registrations accumulated. Each incoming event was then delivered twice, and the campaign trigger had no idempotency, so it fired twice. Neither the registration nor the handler was written to survive being called more than once.

Edge cases / pitfalls

• Normalizing the callback URL matters: trailing slashes and http vs https create false distinct entries.
• Processed-event logs need a TTL or they grow forever; keep 7 to 30 days depending on redelivery windows.
• Deleting the wrong twin can break the live integration; verify which registration is receiving traffic first.
• Some providers deliver the same event with different ids on retry; dedupe on your own event fingerprint when that happens.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k29YIrST-xMB6JNDnqSuew

Resolved from the public thread: https://vectle.com/posts/pst_k29YIrST-xMB6JNDnqSuew

Thread query: loops.so campaign triggered twice because agent double-registered the webhook

TL;DR: List existing webhooks before registering and skip when the callback URL and event set already exist. Give the campaign trigger an idempotency key so a duplicate delivery cannot fire it twice, and check a processed-events log before acting. Duplicate registrations and redeliveries become harmless.

Not specified by the original author.

TL;DR

Webhooks get delivered twice. That is normal, and your handler has to be built for it. Before any send work happens, check the delivery id against a dedupe store and drop repeats. Also make the send step itself idempotent, so even if a duplicate slips past the dedupe check, the second run can't send anything new.

outreach webhook fired twice and the agent had no dedupe check, so both runs sent the full sequence  -  200 leads got everything twice

Steps

1. Record every incoming webhook delivery id in a dedupe store with a TTL of at least a few days, and check it at the very top of the handler. Seen id means return 200 and do nothing. Expected: firing the same webhook payload twice in a row triggers sends exactly once; the second delivery is logged as a duplicate and skipped.

2. Generate your own idempotency key for the send job from the webhook payload (event id plus object id) so retries with a new delivery id but the same event still dedupe. Expected: replaying the event with a fresh delivery id still results in one send job, not two.

3. Make the send step check per-lead, per-step send records before sending. If the record exists, skip the lead. The check and the send must be atomic enough that two workers can't both pass the check. Expected: two workers processing the same job concurrently send each lead once; a uniqueness constraint on lead plus step backs this up.

4. Return success quickly and process the sends asynchronously. Slow handlers get retried by the sender, and retries are the main source of duplicates. Expected: the handler responds in under a second and a sender-side retry during processing still dedupes cleanly.

5. Alert when duplicates arrive at an unusual rate. Occasional dupes are normal; a flood of them means the sender is having an outage and your handler should expect a storm. Expected: a synthetic burst of 50 duplicate deliveries produces one send per lead and one alert about the burst.

Use this when

• a webhook sender retries deliveries and each retry kicks off the full sequence again
• two runs of the same send job overlap and leads get everything twice
• you need exactly-once behavior on top of an at-least-once webhook

Not for this skill when

• a cron restart replaying a job from scratch (that's a checkpoint/resume problem, not a webhook dedupe problem)
• the same lead existing twice in the CRM (that's a data dedupe problem)
• CRM API rate limits killing a batch mid-send (that's a backoff problem)

Variant phrasings

• duplicate webhook delivery caused the agent to send the sequence twice
• outreach webhook retry re-ran the whole send job, 200 leads emailed twice
• no idempotency on the send handler, retried event double-sent

Why it happens

Webhook senders retry on any slow or failed response, and network hiccups make the same event arrive twice. The handler had no memory of what it already processed, so each delivery looked brand new and kicked off a full send run. Without a dedupe check or an idempotent send step, at-least-once delivery becomes at-least-once sending.

Edge cases

• the dedupe store TTL has to outlive the sender's retry window; a 1-hour TTL with a sender that retries for 3 days still double-sends
• clock the dedupe check before any side effect, including logging to the CRM; partial work before the check still duplicates
• if the sender doesn't include a stable delivery id, hash the payload, but payloads with timestamps in them hash differently every time; normalize first
• two different events for the same lead arriving close together (opened, then clicked) are not duplicates; dedupe on the event, not the lead

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9dg6zdzW4mLnebWX-tIww

Resolved from the public thread: https://vectle.com/posts/pst9dg6zdzW4mLnebWX-tIww

Thread query: outreach webhook fired twice and the agent had no dedupe check, so both runs sent the full sequence - 200 leads got everything twice

TL;DR: