Lever 409 "candidate already exists" when the agent's dedup check raced the create call

Lever 409 "candidate already exists" when the agent's dedup check raced the create call

TL;DR

The dedup check ran, found nothing, and then a concurrent process created the candidate before the create call landed: classic check-then-act race. Handle the 409 as the expected outcome: on 409, fetch the existing candidate and continue with it. The 409 is not an error; it is the dedup working late.

409 Conflict: "candidate already exists" (Lever, dedup check raced create)

Steps

1. Confirm the race: check timestamps of the dedup check, the create, and the competing write. Expected: The competitor landed in between.

2. Change the create path to handle 409: catch it, fetch the existing candidate by email, and proceed with that record. Expected: The 409 becomes a normal branch.

3. Keep the dedup check as an optimization, not a guarantee; the 409 handler is the correctness. Expected: Both layers exist.

4. Reduce the race window where cheap: dedup and create in quick succession, or serialize per-email. Expected: Races get rarer.

5. Log 409-handled creates separately so you can see how often the race fires. Expected: The race rate is visible.

When to use

• Lever 409s despite a dedup check
• concurrent writers exist
• the check and create are separate calls

When not to use

• there is no concurrency (then the dedup check itself is broken)
• the 409 is for a different conflict (read the message)
• duplicates are acceptable (then ignore the 409 deliberately)

Tool compatibility

• Lever API
• concurrent candidate creation

Variant phrasings

• "lever 409 candidate already exists race"
• "dedup check raced create"
• "lever conflict duplicate candidate"

Why it happens

Check-then-act is never atomic across two API calls: anything can happen between the check and the act, including another agent doing the same thing. The 409 is the server's way of completing the dedup the client could not. Code that treats it as failure fights the API; code that handles it embraces it.

Edge cases

• per-email serialization (a lock or queue) eliminates the race but adds a bottleneck
• the fetched-on-409 record may be mid-creation by the competitor; retry the fetch
• log the competitor when identifiable; two writers often means a design to simplify

Provenance

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

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

Thread query: Lever 409 "candidate already exists" when the agent's dedup check raced the create call

TL;DR: The dedup check ran, found nothing, and then a concurrent process created the candidate before the create call landed: classic check-then-act race. Handle the 409 as the expected outcome: on 409, fetch the existing candidate and continue with it. The 409 is not an error; it is the dedup working late.