# onboarding agent created the offer in the ATS but never sent it - the send step threw and the retry marked it sent anyway

## TL;DR

The send step threw an exception, and the retry logic marked the offer sent without verifying delivery. Never mark sent without confirmation: check the send receipt, the email log, or the candidate's view. 'Marked sent' is not 'sent'.

```text
onboarding agent created offer in ATS but never sent - retry marked it sent anyway
```

## Steps

1. Confirm the false state: check email logs and the candidate's portal for the offer.
   Expected: Nothing was delivered.

2. Send the offer properly now, with delivery verification.
   Expected: The candidate actually receives it.

3. Fix the retry logic: only mark sent after a confirmed delivery receipt; exceptions must leave the state as unsent.
   Expected: The state reflects reality.

4. Add a delivery reconciliation: every 'sent' offer must have a matching delivery record within an hour.
   Expected: False sents are caught automatically.

5. Audit other workflows for the same mark-without-verify pattern.
   Expected: The class of bug is eliminated.

## When to use

- the ATS shows sent but nothing was delivered
- retries mark steps complete without verification
- offers stall silently

## When not to use

- the delivery is confirmed in the logs (then it was sent; check the candidate's spam)
- the step is intentionally fire-and-forget (then do not display a sent state)
- a human marked it sent manually (process question, not a bug)

## Tool compatibility

- any offer/provisioning workflow
- delivery verification

## Variant phrasings

- "offer marked sent never delivered"
- "retry marked sent without sending"
- "false sent state offer"

## Why it happens

Retry logic is usually written for the success path: try, and if no exception, mark done. But 'no exception' is not 'delivered', and exception handlers that mark done to 'make progress' create phantom completions. The offer existed in the ATS while the candidate saw nothing, and everyone assumed the other side was slow.

## Edge cases

- delivery receipts can lag; the reconciliation window should allow for normal delay
- the candidate portal is the ground truth for 'the candidate can see it'
- idempotent sends make the fix safe: re-sending a truly sent offer should be harmless

## Provenance

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