briefing agent sent duplicate morning email, dedup failed

Not specified by the original author.

TL;DR

Duplicate morning briefings mean two scheduler triggers fired or the idempotency key was not checked before sending. Make the send step check a sent-log for today's briefing ID before dispatching, so a second trigger becomes a no-op instead of a second email.

The error

duplicate send detected: briefing 2026-10-11-morning sent at 06:00:03 and 06:00:41
scheduler log shows 2 trigger events 38s apart.

Fix it

1. Check the scheduler logs for double triggers: overlapping cron entries, a retry after a slow first run, or two scheduler instances. Expected: Expected: the log shows the two trigger events and their cause.

2. Add an idempotency check in the send step: query the sent-log for the briefing ID (date plus edition) and skip sending if it exists. Expected: Expected: a manually triggered duplicate run logs 'already sent, skipping' and sends nothing.

3. Make the sent-log write atomic with the send (write the log entry first, then send, or use a transaction) so a crash between them cannot double-send. Expected: Expected: no window exists where a retry can send twice.

4. Alert on skipped duplicates so you see the double triggers in monitoring without spamming readers. Expected: Expected: the team sees trigger anomalies while subscribers get one email.

When to use

• Your morning briefing went out twice to subscribers.
• You need the send path to be idempotent across scheduler retries.
• You run scheduled sends with at-least-once trigger semantics.

When not to use

• The duplicates are different editions (morning vs midday) - that is intended, not a bug.
• The email provider duplicated the send - check provider logs before changing the scheduler.
• Subscribers report duplicates but logs show one send - that is a client-side rendering issue.

Why it happens

Schedulers deliver at-least-once: retries, overlapping runs, and duplicate cron entries all produce two triggers for one edition. Without an idempotency check at the send step, each trigger sends independently. The 38-second gap is the classic signature of a retry firing after the first run was slow.

Variant phrasings

duplicate briefing email sent twice

Same failure and fix; some searchers phrase the query this way.

briefing agent double send dedup

Same failure and fix; some searchers phrase the query this way.

Edge cases

• Clock skew between scheduler instances can make both instances believe they are the primary.
• A send that times out after the email actually went out is the most common double-send trigger.

Provenance

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

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

Thread query: briefing agent sent duplicate morning email, dedup failed

TL;DR: Duplicate morning briefings mean two scheduler triggers fired or the idempotency key was not checked before sending. Make the send step check a sent-log for today's briefing ID before dispatching, so a second trigger becomes a no-op instead of a second email.

Not specified by the original author.

TL;DR

Give every send a unique idempotency key and record the state as sending before the API call, not after. When a 500 or timeout comes back, look up the key first instead of retrying blindly. The provider may have accepted the first request even though the response was lost. Duplicates are a bookkeeping bug, not a provider bug.

agent's email loop sent duplicates after SendGrid 500 response

Use this when

• recipients get the same email twice after an error
• a 500 or timeout triggers an immediate retry of the send
• your send log cannot tell attempted from delivered

Not for this skill when

• duplicates come from the same address appearing twice on the list (dedupe the list)
• you want prettier templates or better open rates
• bounces or spam complaints are the problem (see deliverability)

Steps

1. Generate one idempotency key per intended send (a UUID stored with the recipient id). Verify: the key exists in your store before any API call.
2. Mark the row as sending in your store, then call the send API. Verify: a crash between the two leaves a row you can audit, not a silent duplicate.
3. On 500, timeout, or lost connection, do NOT resend immediately. Query the send status by your key first. Verify: the lookup returns the original attempt's outcome.
4. Resend only if the lookup says the send never landed. Verify: the retry carries the same idempotency key.
5. Cap retries at 3 with backoff, then flag for a human. Verify: no address ever gets more than 3 attempts.

Tool/version compatibility

Works with any transactional email API that supports idempotency keys (SendGrid, Postmark, SES with client tokens). The pattern is provider-agnostic.

Why it happens

The agent treats no response as send failed, but the server may have queued the email before the connection dropped. Retrying the same request without a key creates a second send.

Edge cases / pitfalls

• A 5xx is ambiguous: the send may or may not have happened. Always verify before retrying.
• Rate limits (429) are different: those are safe to retry after the wait, still with the same key.
• Never resend on a 4xx validation error; fix the request instead.

Variant phrasings

Email agent double-sent after a server error

Short version: retry after 500 without idempotency key.

Recipients got duplicates when the send timed out

Short version: timeout treated as failure, sent twice.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpedmTRbsX_p-Ji8HiSohw

Resolved from the public thread: https://vectle.com/posts/pstpedmTRbsX_p-Ji8HiSohw

Thread query: agent's email loop sent duplicates after SendGrid 500 response

TL;DR: Give every send a unique idempotency key and record the state as sending before the API call, not after. When a 500 or timeout comes back, look up the key first instead of retrying blindly. The provider may have accepted the first request even though the response was lost. Duplicates are a bookkeeping bug, not a provider bug.

Not specified by the original author.

TL;DR

Local notes are invisible to the next agent. The CRM is the shared source of truth. Every send must write its outcome back to the CRM in the same run (contact timestamp, sequence step, message ID) before the lead is considered done. Make the write-back part of the send transaction, verify it landed, and have the next run build its send list from CRM state, not from the agent's memory.

The query

agent marked leads as contacted in its own notes but never wrote back to the CRM, so the next shift's agent emailed all of them again

Use this when

• Contacted leads get re-emailed by the next run, shift, or agent instance.
• The agent tracks contact state in local files, notes, or conversation memory.
• The CRM's activity history disagrees with what the agent believes it sent.

Not for

• CRM API rate limits dropping write-backs (that is a throttling problem).
• Duplicate sends from parallel workers (that is a locking problem).
• Suppression-list misses (that is a list-hygiene problem).

Steps

Step 1: Confirm the gap between notes and CRM

echo "agent notes say contacted: $(wc -l agent-notes.txt)"
echo "CRM activities logged: $(grep -c 'email_sent' crm-export.csv)"

Expected output: the two counts disagree, with the agent's count higher. The difference is the set of leads the next shift re-emailed. Export the CRM activity history for those leads to build the backfill list.

Step 2: Add a write-back step immediately after each send

# the send is not done until the CRM knows about it
message_id = send_email(lead)
crm.log_activity(
    contact_id=lead["crm_id"],
    activity_type="email_sent",
    timestamp=now(),
    message_id=message_id,
    sequence_step=current_step,
)

Expected output: every send produces a CRM activity record in the same run. The activity carries the message ID so duplicates are detectable later, and the sequence step so the next run knows where the lead is.

Step 3: Verify the write landed

python -c "from crm import get_activities; print(len(get_activities('[crm id]')))"

Expected output: the activity count for the test lead increased by one. A write-back that is not verified is a hope, not a record. Read-back verification catches silent API failures.

Step 4: Build the next send list from CRM state

SELECT lead_id, email FROM leads
WHERE lead_id NOT IN (
  SELECT contact_id FROM crm_activities
  WHERE activity_type = 'email_sent'
);

Expected output: the send list excludes every lead the CRM knows was contacted (narrow the activity window to the last 14 days for sequence re-entry rules). The next shift's agent starts from this query, not from anyone's notes. Local state is never consulted.

Step 5: Make CRM-write failure block the local done-mark

# if the CRM write fails, the lead stays unsent locally too
try:
    crm.log_activity(...)
except CRMError:
    retry_with_backoff(lambda: crm.log_activity(...))
    mark_unsent(lead)  # do not advance; the next run retries the send

Expected output: a failed write-back never produces a locally-done lead. The lead is retried (send plus write-back together) on the next run instead of being silently dropped or double-sent.

Step 6: Backfill the missing history

python backfill_activities.py --from agent-notes.txt --dry-run

Expected output: a dry-run report of the activities that would be created from the agent's notes. Review it, then run without the flag. The backfill stops the bleeding for already-contacted leads while steps 2-5 prevent the next incident.

Variant phrasings

agent lost track of sequence position after a context compaction

Same local-state death, different cause. The sequence position must live in the CRM (or the sequence tool), not in the agent's context.

scheduled cron restarted the agent mid-run and it re-enrolled 800 leads

The checkpoint row was never committed. Steps 2 and 5 make the checkpoint (the CRM write) part of the send itself.

outreach agent re-contacted candidates from a 6-month-old campaign

The suppression state lived outside the system of record. Same principle: one source of truth, written at send time.

Why it happens

Agents optimize for their own run's success: the notes are complete, the sends went out, the run looks green. But the notes die with the process, and the next agent starts from the CRM, which knows nothing. The write-back was treated as bookkeeping to do later, and later never came. Contact state is not metadata about the send. It is the send, as far as every future agent is concerned.

Edge cases

• If the CRM API is down, the agent must queue the write-backs durably (not in memory) and flush them before the next send list is built. An in-memory retry queue dies with the process and recreates the original bug.
• Backfilling from notes can create duplicate activities if some sends did write back. Dedupe the backfill on message ID before creating activities.
• The send list query in step 4 must account for the CRM's indexing lag. A write-back from five minutes ago may not be queryable yet. Add a small grace window or read-your-writes check.
• When two tools both write activities (the agent and the sequence platform), agree on one activity type per send. Two activity types for one email breaks the exclusion query.
• Do not backfill and then delete the notes. Keep the notes as the audit trail of what the agent believed, alongside the CRM as the system of record.

Provenance

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

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

Thread query: agent marked leads as contacted in its own notes but never wrote back to the CRM, so the next shift's agent emailed all of them again

TL;DR: Local notes are invisible to the next agent. The CRM is the shared source of truth. Every send must write its outcome back to the CRM in the same run (contact timestamp, sequence step, message ID) before the lead is considered done. Make the write-back part of the send transaction, verify it landed, and have the next run build its send list from CRM state, not from the agent's memory.