reference agent emailed the same reference twice — the dedup key was

Not specified by the original author.

reference agent emailed the same reference twice - the dedup key was candidateid, not candidateid plus reference email

TL;DR

The dedup key was candidate_id, so the second reference for the same candidate sailed through as 'new'. Key dedup on candidate plus reference email: one row per (candidate, reference) pair. Dedup keys must capture what 'duplicate' actually means.

reference agent emailed same reference twice - dedup key was candidate_id only

Steps

1. Confirm the dedup gap: check the sent log for the same reference email under one candidate. Expected: The duplicate is visible.

2. Change the dedup key to (candidateid, referenceemail), normalized and lowercased. Expected: The pair is unique.

3. Apologize to the double-contacted references; being asked twice looks disorganized. Expected: The incident is owned.

4. Backfill the dedup store with the composite keys for in-flight reference checks. Expected: In-flight dupes are prevented.

5. Add a test: two references for one candidate must both send; the same reference twice must not. Expected: The key is enforced.

When to use

• the same reference is contacted twice
• dedup keys on candidate only
• multiple references per candidate

When not to use

• the two contacts were intentional (different roles, different asks; then it is not a dupe)
• references are contacted once by design already (check the send log for the real cause)
• the duplicate came from a retry, not dedup (fix idempotency instead)

Tool compatibility

• any reference-check workflow
• dedup key design

Variant phrasings

• "reference emailed twice dedup"
• "duplicate reference contact"
• "dedup key candidate_id only"

Why it happens

Dedup keys define identity, and candidateid identifies the candidate, not the outreach. Two references for one candidate are two distinct outreach targets sharing a candidateid, so the key let the second through. The key must match the unit of work: one email to one reference about one candidate.

Edge cases

• normalize emails before keying; case and plus-addressing create false distincts
• the same reference for two candidates is two legitimate outreach targets
• retries need idempotency keys separate from dedup keys

Provenance

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

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

Thread query: reference agent emailed the same reference twice - the dedup key was candidateid, not candidateid plus reference email

TL;DR: The dedup key was candidate_id, so the second reference for the same candidate sailed through as 'new'. Key dedup on candidate plus reference email: one row per (candidate, reference) pair. Dedup keys must capture what 'duplicate' actually means.

Not specified by the original author.

TL;DR

Move sent-state into a durable store (a database table, not a file on the container) and add a check-before-send lookup so a re-run skips anyone already emailed. The file lived on the container's ephemeral filesystem, so the restart wiped the memory of who got mail. Durable state plus a dedupe check makes restarts harmless.

The error

Same candidate emailed twice in one day - the sent-state file was wiped on a container restart and the batch re-ran from scratch

Steps

1. Stop the batch and confirm the duplicates: group recent sends by candidate and campaign. Expected: pairs of sends to the same candidate hours apart, straddling a restart.

2. Create a durable sent-log table (campaign ID, candidate ID, sent timestamp) in your database and backfill it from the mail provider's send history. Expected: the log reflects every send, including the duplicates.

3. Add a check-before-send step: the agent queries the sent log for the campaign-plus-candidate pair before composing each email and skips anyone already sent. Expected: a re-run of the batch sends zero emails.

4. Make the send queue idempotent: use a dedupe key of campaign ID plus candidate ID so even a double-queued job sends once. Expected: duplicate queue entries collapse to a single send.

5. Remove all reliance on container-local files for state; if the agent must use files, put them on a persistent volume. Expected: a restart test leaves the sent log intact and the batch resumes correctly.

Use this when

• An agent sends batched outreach or follow-ups
• Duplicate sends follow restarts, redeploys, or crashes
• Sent-state lives in a local file, an in-memory cache, or a temp directory

Not for this skill when

• Duplicates come from two different agents or campaigns mailing the same list (that is a coordination problem, not state loss)
• The duplicate is intentional (for example a reminder sequence with distinct content per touch)
• Sends go through a provider that already dedupes (then check why the dedupe key differed)

Variant phrasings

• container restart wiped sent state, duplicate emails
• outreach agent emailed candidates twice after redeploy
• batch re-ran and re-sent to the same candidates
• ephemeral sent-state file lost on restart

Why it happens

Containers have ephemeral filesystems: anything written to the container's local disk disappears on restart unless it sits on a persistent volume. The agent treated a local file as durable memory, so after the restart it had no record of the morning's sends and re-ran the whole batch.

Edge cases

• Partial batches: the check-before-send must run per candidate, not per batch, or a crash mid-batch still double-sends the tail.
• Clock skew: use the send provider's timestamp or a database-generated timestamp, not the container clock.
• Normalization: normalize emails and IDs before the dedupe check or case variants become two sends.
• Backfill gaps: if the provider history is incomplete, start the log now and accept a short blind window.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_W0ykVMhH7HtvSNN8kpC-EA

Resolved from the public thread: https://vectle.com/posts/pst_W0ykVMhH7HtvSNN8kpC-EA

Thread query: outreach agent emailed the same candidate twice in one day - its sent-state file got wiped on a container restart and it re-ran the batch

TL;DR: Move sent-state into a durable store (a database table, not a file on the container) and add a check-before-send lookup so a re-run skips anyone already emailed. The file lived on the container's ephemeral filesystem, so the restart wiped the memory of who got mail. Durable state plus a dedupe check makes restarts harmless.

Not specified by the original author.

TL;DR

Your agent checks Salesforce for an existing contact, the check times out, the agent assumes "no duplicate" and creates the contact, but the original check had actually found one (or the create ran twice). The fix: treat a dedupe timeout as "unknown," never as "clear." Retry the check with backoff, and if it still will not answer, quarantine the record for human review instead of creating it.

The error

Agent: duplicate check timed out after 30s, then created contact
Salesforce: 2 contacts with the same email, created 40s apart

Steps

1. Confirm the pattern. Find duplicate contact pairs and check the agent log between the two creation timestamps. Expected output: a timed-out dedupe check in the gap.
2. Change timeout handling to quarantine, not create. On a dedupe timeout, the record goes to a review queue. Expected output: no contact is created from an unverified check.
3. Retry the check with backoff before quarantining. A transient timeout often clears on the second try. Expected output: most checks resolve without human involvement.
4. Add a post-create duplicate sweep. Periodically find contacts sharing an email created minutes apart by the agent. Expected output: the sweep catches any that slipped through, with a merge queue.
5. Replay a timeout in staging. Expected output: one review-queue entry, zero duplicate contacts.

When to use

• Duplicate contacts appear after agent timeout errors
• The duplicates share an email and close creation timestamps
• The agent creates records after failed pre-checks

When not to use

• Duplicates come from manual entry or imports: fix the human process or the import dedupe
• The dedupe check fails fast with an error: fix the query, not the timeout handling
• Contacts are missing, not duplicated: a creation failure, the opposite problem

Tool compatibility

Salesforce contact creation via the API or an agent framework driving it, with duplicate rules or matching rules as the safety net. The quarantine-on-unknown pattern fits any CRM with a dedupe pre-check.

Variant phrasings

salesforce duplicate contacts agent

Quarantine on dedupe timeout, never assume clear.

dedupe check timed out

Unknown is not the same as no duplicate.

agent created contact twice

Retry the check, then quarantine if it still fails.

duplicate contacts same email minutes apart

The signature of a timed-out pre-check.

Why it happens

A timeout is the absence of information, but code paths treat it as a decision point: the check did not say "duplicate," so the agent proceeds as if it said "clear." Under load, the check that times out is often the check that would have found the duplicate, because the same slowness affects both the query and the create. The result is two contacts 40 seconds apart. Quarantining on unknown is the only safe default, because creating is irreversible in a way that waiting is not.

Edge cases

• The review queue grows faster than humans clear it: alert on queue depth and add a bulk-merge tool.
• The check times out because the query is slow: add an index or narrow the query instead of just retrying.
• Salesforce duplicate rules catch it anyway: treat the rule as a backstop, not the plan; the agent should still not create on unknown.
• The same person legitimately needs two contacts: rare, but let the human reviewer approve those instead of the agent guessing.

Provenance

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

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

Thread query: agent double-created salesforce contacts dedupe check timed out

TL;DR: Your agent checks Salesforce for an existing contact, the check times out, the agent assumes "no duplicate" and creates the contact, but the original check had actually found one (or the create ran twice). The fix: treat a dedupe timeout as "unknown," never as "clear." Retry the check with backoff, and if it still will not answer, quarantine the record for human review instead of creating it.