**TL;DR:** Expire the old confirmation link on every reschedule and allow only one live confirmation per candidate. The loop is a state bug: rescheduling re-armed the confirm step while every previous link still resolved. Revoke first, then send the fresh link, and make reschedules idempotent.

```text
scheduler agent set up a loop: every reschedule triggered a 'confirm your slot' email and candidates kept clicking the stale link
```

1. Read the reschedule handler and check what happens to the previous confirmation token.
   Expected: the handler sends a new confirm email but never invalidates the old token.
2. On reschedule, revoke the previous confirmation link before generating the new one.
   Expected: clicking the old link now shows "this slot was moved, here is the current one" instead of confirming the stale slot.
3. Make reschedule idempotent: the same candidate moved to the same new slot twice produces one confirm email, not two.
   Expected: replaying the reschedule request changes nothing after the first run.
4. Enforce one pending confirmation per candidate: a new reschedule supersedes, never stacks.
   Expected: a candidate with three reschedules has exactly one live link.
5. Add a rate guard: more than two reschedules in a day routes to a human instead of sending another automated email.
   Expected: the third reschedule in a day creates a recruiter task, not an email.

## Use this when
- Candidates confirm slots from old emails after a reschedule.
- Each reschedule multiplies the confirmation emails instead of replacing them.
- Confirmation clicks seem to re-trigger scheduling actions.

## Not for this skill when
- The loop is in the candidate's email client auto-clicking links (link prefetch); fix with one-time tokens, not reschedule logic.
- The confirmations are fine but the calendar events duplicate (that is an event-creation bug).
- Reschedules are rare and each one is correct; the issue is email volume, not stale links.

## Variant phrasings
- reschedule email loop with stale confirmation links
- candidates clicking old confirm links after interview moved
- every reschedule sent another confirm your slot email
- confirmation link still worked after the interview was rescheduled

## Why it happens
Confirmation emails are events that mutate state, and the reschedule flow treated "send confirm" as a fresh action each time without retiring the previous one. Every historical link stayed a live button. Candidates clicking any of them re-confirmed outdated state, which in some setups re-triggered scheduling actions, feeding the loop. The missing piece is lifecycle: each confirmation token needs exactly one live generation at a time.

## Edge cases
- The candidate clicks the old link in the seconds between revoke and the new send: the revoke message must point them at the newest email, not a dead end.
- Two recruiters rescheduling the same candidate at once: serialize reschedules per candidate so the revoke-then-send pairs cannot interleave.
- Email clients that prefetch links: a prefetch must never count as a confirmation. Require an explicit click-through page.
- A candidate who already confirmed the old slot before the reschedule: they need a "your interview moved" notice, not just a new link.

## Provenance

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