agent deleted 200 candidates from a req - the sync from ATS ran against the wrong job ID

agent deleted 200 candidates from a req - the sync from ATS ran against the wrong job ID

TL;DR

The sync job took a job ID parameter, got the wrong one, and deleted 200 candidates from the wrong req. Scope every sync to an explicit job, dry-run destructive syncs first, and require the affected count to be sane before committing. A sync that can delete needs the same care as a deploy.

agent deleted 200 candidates from a req - sync ran against wrong job ID

Steps

1. Stop the sync job immediately and assess: which req lost candidates, and are they archived or hard-deleted. Expected: The blast radius is known.

2. Restore from the ATS audit log or backup. Expected: The candidates are back.

3. Add a job-ID verification step: the sync must confirm the req name matches expectations before touching data. Expected: Wrong IDs fail before acting.

4. Require dry-run for destructive syncs: report what would change, get approval above a threshold. Expected: Mass changes need eyes.

5. Cap the blast radius: refuse to delete more than N candidates without explicit confirmation. Expected: The next mistake is bounded.

When to use

• candidates vanished after a sync
• a sync takes a job ID parameter
• destructive syncs run unattended

When not to use

• the deletion was intentional (then it needs the same guards anyway)
• the sync is read-only (it cannot delete; verify that claim)
• candidates were moved, not deleted (check the move log)

Tool compatibility

• any ATS sync agent
• dry-run patterns

Variant phrasings

• "sync deleted candidates wrong job"
• "wrong job ID sync deletion"
• "mass candidate deletion sync"

Why it happens

Sync jobs are usually built for the happy path: correct job ID in, fresh data out. The wrong-job case turns a routine sync into a mass deletion, and nothing in the job questioned it. Destructive operations need identity verification, dry runs, and blast-radius caps as standard equipment, not afterthoughts.

Edge cases

• the audit log is the restore path; verify it captures deletes before you need it
• dry-run output needs a human-readable diff, or approvers rubber-stamp it
• the count cap needs a sensible default per req size; one size does not fit all

Provenance

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

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

Thread query: agent deleted 200 candidates from a req - the sync from ATS ran against the wrong job ID

TL;DR: The sync job took a job ID parameter, got the wrong one, and deleted 200 candidates from the wrong req. Scope every sync to an explicit job, dry-run destructive syncs first, and require the affected count to be sane before committing. A sync that can delete needs the same care as a deploy.