scheduling agent invited a candidate who had already withdrawn - the ATS stage webhook fired but the scheduler's...

TL;DR: Revalidate the candidate's stage with a live ATS read at invite time, and treat webhooks as invalidations, not as the only update path. The invite went out because the scheduler's cached stage was hours older than the withdrawal. A short cache TTL plus a just-in-time check closes the window.

scheduling agent invited a candidate who had already withdrawn  -  the ATS stage webhook fired but the scheduler's cache hadn't refreshed

1. Fetch the candidate's current stage directly from the ATS API, bypassing the scheduler's cache.

Expected: the live read shows the withdrawn stage, proving the cache was stale.

1. Abort the invite and mark the scheduling workflow for that candidate as cancelled.

Expected: no invite sends, and the workflow state records the cancellation reason.

1. Shorten the stage cache TTL to minutes and wire ATS status webhooks to invalidate the cached record on arrival.

Expected: a stage change is visible to the scheduler within minutes, not hours.

1. Add a pre-send gate: every invite does a live stage read right before sending, and terminal stages block the send.

Expected: in a test with a freshly withdrawn candidate, the gate stops the invite.

1. Add a daily audit that lists invites sent in the last 24 hours and flags any for candidates in terminal stages.

Expected: the audit returns empty on a healthy day and names names when the gate is bypassed.

Use this when

• Invites or outreach go to withdrawn, rejected, or hired candidates.
• The agent caches ATS stage and relies on webhooks to stay fresh.
• Webhook delivery lags or the cache TTL is long.

Not for this skill when

• The webhook never fired at all (that is a webhook delivery failure; fix the subscription).
• The ATS stage itself was wrong in the UI, not just in the agent's cache.
• The candidate withdrew after the invite was already correctly sent.

Variant phrasings

• scheduler invited a withdrawn candidate
• stale candidate stage caused a bad interview invite
• ATS webhook arrived but the cache still showed the old stage
• interview scheduled for a candidate who already dropped out

Why it happens

Caches trade freshness for speed, and webhooks are the only freshness mechanism here. Webhook delivery has its own lag, cache TTL adds more, and the two stack into a stale window. The scheduler happened to book inside that window. The deeper fix is to never trust cached state at the moment of an outward-facing action: re-read the source of truth right before you act on it.

Edge cases

• Webhooks arriving out of order: a delayed older event can overwrite a newer stage. Apply events only if their timestamp is newer than the cached one.
• The candidate withdraws between the live read and the send: keep the window tiny, and accept that a same-second race needs a human apology, not more code.
• Custom stage names per job: the terminal-stage list must be per-job or per-workflow, not global.
• Bulk stage changes: a recruiter moving fifty candidates at once can flood webhooks. The pre-send gate still catches each one.

Provenance

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