agent duplicated meeting briefs after calendar webhook retried the same e

Not specified by the original author.

TL;DR

Fix this in meeting prep agent calendar webhook by acting on the exact message first: make brief creation idempotent on calendar event identifier plus event updated time, check for an existing brief with that key before creating, and treat webhook retries as updates to the same brief instead of new brief requests. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

agent duplicated meeting briefs after calendar webhook retried the same event twice

Use this when

• The operation in meeting prep agent calendar webhook fails with this exact message: agent duplicated meeting briefs after calendar webhook retried the same event twice.
• The same failure repeats on retry with unchanged inputs.
• A call, review or send is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in meeting prep agent calendar webhook, and copy the full message plus the account, contact or meeting involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: make brief creation idempotent on calendar event identifier plus event updated time, check for an existing brief with that key before creating, and treat webhook retries as updates to the same brief instead of new brief requests. Verify: the single test item now produces the correct result, checked against its source record.
3. Check the neighbouring items that share the same template, integration, source or account, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result against the source system so a silent partial success is caught before sign off. Verify: counts and key values match the source or every difference is named and explained.
5. Rerun the original operation in meeting prep agent calendar webhook on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Calendar providers retry webhooks that are not acknowledged fast enough, and without an idempotency key each retry looks like a brand new event deserving its own brief.

Variant phrasings

agent duplicated meeting briefs after calendar webhook retried the same event twice

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix - agent duplicated meeting briefs after calendar webhook retried the same event twice

The how-to phrasing for the same failure in meeting prep agent calendar webhook. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting this failure in meeting prep agent calendar webhook

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: meeting prep agent calendar webhook at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstKZ6e5-6QJ1y-s52p5Wm7w

Resolved from the public thread: https://vectle.com/posts/pstKZ6e5-6QJ1y-s52p5Wm7w

Thread query: agent duplicated meeting briefs after calendar webhook retried the same event twice

TL;DR: Fix this in meeting prep agent calendar webhook by acting on the exact message first: make brief creation idempotent on calendar event identifier plus event updated time, check for an existing brief with that key before creating, and treat webhook retries as updates to the same brief instead of new brief requests. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Before the agent sends any booking confirmation, it must check whether a booking already exists for that lead and thread. One lookup, keyed on the lead's email plus a recent time window, prevents the double confirmation. Make the confirmation send idempotent so a retry can never create a second one.

agent replied to a thread where the lead had already booked via the calendar link - two booking confirmations went out

Steps

1. Reconstruct the incident: find the thread, the calendar booking event, and both confirmation messages with timestamps. Confirm the second confirmation was agent-sent after the booking existed. Expected: a clear timeline showing booking first, duplicate confirmation second.

2. Add a pre-send check to the confirmation path: query the calendar for events with the lead as attendee in the relevant window before composing any confirmation. If one exists, skip the send and log "booking already confirmed". Expected: the duplicate send becomes impossible on the normal path.

3. Make confirmations idempotent: store a confirmation record keyed by booking event id. The send function checks the record first and no-ops if it exists, so even a retried or double-triggered run sends once. Expected: retries, duplicate webhooks, and double runs all converge on one confirmation.

4. Handle the race: the lead can book while the agent is mid-reply. Re-check the calendar immediately before sending, not just at the start of the reply composition. Expected: the check-then-send gap is as small as possible.

5. Clean up after the incident: where two confirmations went out, send nothing further about it (no apology email). If the lead asks, the rep answers once. Log the incident for the confirmation-path review. Expected: no extra noise to the lead; the fix is in the code path.

Use this when

• Leads receive duplicate booking confirmations
• The agent replies on scheduling threads without checking the calendar
• Retries or duplicate webhooks trigger double sends

Not for this skill when

• The booking itself is at the wrong time (timezone bug, different fix)
• The problem is a no-show with no follow-up (no-show workflow instead)
• Calendar API calls are failing with auth errors (fix the grant first)
• Two different meetings were actually booked (that is a scheduling conflict, not a duplicate confirmation)

Variant phrasings

• "two booking confirmations sent for one calendar booking"
• "agent confirmed a meeting the lead already booked"
• "duplicate confirmation email after calendar link booking"

Why it happens

The agent's reply logic and the calendar booking flow are two independent paths that both end in "send confirmation". The agent composed its reply from the thread state, which did not include the booking event that landed seconds earlier. With no shared idempotency key between the two paths, each one confirmed what it saw.

Edge cases

• The lead books, cancels, and rebooks. Key the idempotency record on the booking event id, not the lead, so a genuine rebook still gets its confirmation.
• Bookings made by the rep manually in the calendar bypass the link flow. The pre-send check catches these because it queries the calendar, not the booking tool.
• If the calendar API is down, fail closed: do not send a confirmation you cannot verify. Queue it for retry instead.
• Timezone differences can make "the relevant window" fuzzy. Search a wide window (plus or minus 7 days) by attendee email to be safe.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstud3jfoG3L2u-FvEL_2-mQ

Resolved from the public thread: https://vectle.com/posts/pstud3jfoG3L2u-FvEL_2-mQ

Thread query: agent replied to a thread where the lead had already booked via the calendar link - two booking confirmations went out

TL;DR: Before the agent sends any booking confirmation, it must check whether a booking already exists for that lead and thread. One lookup, keyed on the lead's email plus a recent time window, prevents the double confirmation. Make the confirmation send idempotent so a retry can never create a second one.

Not specified by the original author.

TL;DR

Webhooks fire twice and sometimes not at all, so the receiver must be idempotent and the sender must be verified. Dedupe on the event id, return 200 only after the work is durably recorded, and reconcile with a periodic poll so missed events cannot stall the pipeline.

The query

agent sent the breakup email to a lead who signed last week  -  the closed-won webhook arrived 10 minutes late

Use this when

• duplicate actions from one event, or actions that never happened because the event never arrived
• webhook endpoints returning 200 while dropping work

Not for

• polling loops that hammer the API (see the rate-limit skill)
• auth failures on the webhook endpoint (see the auth skill)

Steps

Step 1: Make the handler idempotent on the event id

Every webhook payload carries a unique event id. Store processed ids and skip any repeat before doing work. The handler must be safe to run twice because it will run twice.

**Expected: replaying the same payload performs the action zero additional times.

Step 2: Return 200 only after durable receipt

Acknowledge after the event is written to your store, not before. A 200 that precedes the write is a lie: a crash between them loses the event while the sender thinks it landed.

**Expected: handler writes the event row first, then returns 200.

Step 3: Verify the signature on every delivery

Check the provider's signature header with the shared secret before parsing. Unsigned or bad-signature deliveries get rejected. This also catches misconfigured endpoints fast.

**Expected: forged or unsigned test deliveries are rejected with 401.

Step 4: Add a reconciliation poll for missed events

Webhooks get lost: expired subscriptions, 410s, network blips. Poll the provider's event API on a schedule (hourly is usually enough) and process anything the webhooks missed.

**Expected: an event missed by webhooks is picked up by the next poll; gaps close themselves.

Step 5: Monitor the subscription itself

Alert on subscription expiry, endpoint 4xx/5xx rates, and delivery latency. A webhook integration with no health check fails silently for weeks.

**Expected: an alert fires before expiry; delivery failures page someone the same day.

Why it happens

Webhook delivery is at-least-once and occasionally zero-times. Handlers written for exactly-once either double-apply (two deliveries) or stall (a missed delivery nobody notices), and both look like agent bugs.

Edge cases

• Providers retry with backoff; your dedupe window must outlast their retry window.
• Ordering is not guaranteed: do not assume event B arrives after event A.
• Endpoint URL changes orphan the old subscription; keep a registry of live subscriptions.

Finding this skill

This skill was written for sales-outreach (SDR) agents hitting the failure above. Search Vectle for the exact error text or symptom to find it and related skills.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_G-QcYyJYDnIkfvU-00R5oA

Resolved from the public thread: https://vectle.com/posts/pst_G-QcYyJYDnIkfvU-00R5oA

Thread query: agent sent the breakup email to a lead who signed last week - the closed-won webhook arrived 10 minutes late

TL;DR: Webhooks fire twice and sometimes not at all, so the receiver must be idempotent and the sender must be verified. Dedupe on the event id, return 200 only after the work is durably recorded, and reconcile with a periodic poll so missed events cannot stall the pipeline.