## TL;DR
A dropped connection should cost seconds, not the whole session. Persist the session state after every item: session id, cursor, and processed item ids. On reconnect, resume from the cursor and replay idempotently so already-processed items are skipped safely.

```text
fraud agent connection dropped mid-review session and failed to resume
```

## Use this when
- A dropped connection kills a review session with no recovery.
- Restarts re-review from the queue head and waste quota.
- Long sessions never survive to completion.

## Not for this skill when
- The API returns errors. That is a provider problem, not a connection problem.
- The agent crashes from a bug. Fix the bug; resume only limits the damage.
- Sessions complete but slowly. That is a performance problem.

## Steps
1. After each reviewed item, write the session id, queue cursor, and processed item ids to durable storage. Verify: the state survives a process kill.
2. On startup, check for an incomplete session before starting a new one. Verify: a restarted agent finds and resumes the old session.
3. Resume from the stored cursor, not from the queue head. Verify: no item is reviewed twice from scratch.
4. Make item processing idempotent: record the outcome keyed by item id so replays are no-ops. Verify: a replayed item changes nothing.
5. Expire abandoned sessions after a TTL and alert. Verify: stale sessions do not pile up or resume ancient work.

## Variant phrasings
### review session dropped cannot resume
Same failure, common phrasing.
### agent connection lost mid review
Symptom-level search.
### resume fraud review after disconnect
Recovery-side wording.

Compatibility: Any long-running review session over a queue. State lives in the agent's own durable store.

## Why it happens
Review sessions hold all their progress in memory: the cursor, the decisions, the context. A dropped connection or a restart wipes it, and the agent either starts over, wasting API quota and time, or abandons the queue. Persisted cursors turn a crash into a pause.

## Edge cases / pitfalls
- Replay markers must be deterministic per item, or replays will double-apply decisions.
- A resume that is too eager can pick up a session another worker already took. Use a session lock or lease.
- Keep the checkpoint write cheap, or checkpointing itself becomes the bottleneck.
- Test resume with a real kill, not just a graceful shutdown. Crashes are the case that matters.

## Provenance

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