interview agent booked 6 candidates into the same panel slot - a race condition: the availability check ran before...

TL;DR: Never let the availability check and the booking be two unlocked steps. Claim the slot with an atomic conditional write (only book if it is still free) or serialize panel-slot bookings through a single queue. The race happened because every read ran before any write committed, so each worker saw a free slot.

interview agent booked 6 candidates into the same panel slot  -  a race condition: the availability check ran before the first write committed, so every read saw a free slot

1. Trace the booking path and confirm the availability check and the event creation are separate calls with no lock between them.

Expected: you can point at the gap where two concurrent runs both pass the check.

1. Add a per-slot claim record with a uniqueness constraint, written before the calendar event is created.

Expected: one claim insert succeeds and the other five fail with a conflict.

1. On a claim conflict, retry the candidate against the next available slot instead of failing the booking.

Expected: all six candidates end up confirmed in distinct slots.

1. If the calendar API supports idempotent event creation, use a deterministic event id per slot so duplicate creates collide instead of duplicating.

Expected: replaying the same booking request returns the existing event, not a second one.

1. Log every claim attempt with the worker id so collisions are auditable after the fact.

Expected: the log shows which worker won each slot and which retried.

Use this when

• Multiple candidates land in the same slot within seconds or minutes of each other.
• Booking runs across parallel workers or retries.
• The availability check and the write are separate API calls.

Not for this skill when

• One worker double-books because it read stale cache (that is a caching bug, not a race).
• The calendar provider itself allows overlapping events and you need provider-side settings changed.
• The duplicate came from a retried request, not concurrent workers (use idempotency keys for that).

Variant phrasings

• two candidates confirmed for the same interview slot
• scheduler race condition double booked the panel
• availability check passed for everyone at once
• concurrent bookings collided on the same slot

Why it happens

Check-then-act is only safe inside a transaction, and calendar APIs do not transact across calls. With N workers, the window between "is it free" and "book it" is wide enough for every worker to read "free" before any of them writes. Scaling the agent fleet scales the collision rate without changing a line of scheduling logic.

Edge cases

• A claim succeeds but the calendar write then fails: the slot looks taken with no event. Expire unfulfilled claims quickly and retry the write.
• Cancellations freeing a slot while retries are queued: the freed slot can re-trigger the same race. Route freed slots through the same claim path.
• Clock skew across workers ordering claims unfairly: fairness does not matter here, exactly-once does. Keep the constraint, not the ordering.
• The losing candidate has no next slot: surface that to the recruiter instead of silently dropping the booking.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstnKxX-IepeJ58GRNCIzedQ