TL;DR: Treat the 409 as good news: the event already exists, so fetch it by ID instead of creating it again. Then make the agent's retry logic expect the 409 and fall through to a read. Retrying a create with the same client-supplied ID will collide every time by design.

```text
Google Calendar API 409 "the requested identifier already exists"
```

1. On receiving the 409, issue a GET for the event using the same calendar and event ID you sent. Expected: a 200 response with the event from the first attempt.
2. Change the agent's create path: catch the 409 and fall through to the GET instead of raising an error. Expected: retries return the existing event cleanly.
3. If the workflow genuinely needs a fresh event, generate a new unique ID per attempt rather than reusing the candidate-derived one. Expected: the create returns 201.
4. Audit the calendar for duplicates the earlier retries may have made under different IDs and remove them. Expected: exactly one event per interview.

## Use this when
- A retried calendar-event create returns 409.
- The agent supplies its own event IDs for idempotency.
- Timeouts preceded the retry.

## Not for this skill when
- The error is 403 rate limiting (back off instead).
- The error is 404 calendar not found (wrong calendar ID).
- The error is 412 precondition failed (etag mismatch).

## Variant phrasings
- "Google Calendar duplicate event id"
- "409 already exists calendar event"
- "calendar event id collision retry"
- "requested identifier already exists"

## Why it happens
The agent sends an explicit event ID for idempotency, the first request succeeds server-side, but the response is lost to a timeout. The retry replays the same ID, and Calendar correctly refuses to create a second event with it.

## Edge cases
- Verify the fetched event's fields before reusing it; the first attempt may have stored stale details.
- Event IDs are unique per calendar, not globally; a 409 names the calendar it collided in.
- Deleting an event frees its ID only after garbage collection; immediate reuse can still 409.

## Provenance

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