agent loop detected: re-verifying the same snapshot repeatedly, job failed

TL;DR

A loop re-verifying one snapshot means the agent completion state is not sticking: results are kept in memory, the success marker is written somewhere the selection logic does not read, or failures reset the whole queue. Persist per-snapshot outcomes, select work only from unverified items, add a detector that halts the run after repeated identical attempts, and report the loop as an agent bug, not a backup result.

agent loop detected: re-verifying the same snapshot repeatedly, job failed

Use this when

• Run logs show the same snapshot identifier verified many times in one run.
• Total verified counts never advance past a fixed point.
• The loop ends only when the job times out or is killed.

Not for this skill when

• A snapshot is re-verified once after its backup was repaired. That is intended behaviour.
• The backup system itself re-runs a verification job. Product-side scheduling.

Steps

1. Trace one looped snapshot through selection, verification and result recording in the logs. Verify: the point where completion state is lost is found
2. Move verification outcomes to durable run state keyed by snapshot identifier and make selection read that state. Verify: a restarted agent skips verified snapshots
3. Add an attempt counter per snapshot with a small cap that fails that item and moves on. Verify: a forced-failure snapshot is attempted the capped number of times, then skipped
4. Add a loop detector that aborts the run with a clear agent error if identical work repeats beyond the cap. Verify: the detector triggers in a test
5. Run the full verification sweep. Verify: each snapshot is verified once and the summary counts match the inventory

Variant phrasings

agent loop same task repeatedly state bug

The state phrasing.

verification job stuck repeating snapshot

The symptom variant.

agent loop detection attempt cap idempotency

The guard wording.

Compatibility: Agent verification loops in Python and TypeScript orchestrators with file, database or queue-backed run state.

Why it happens

Loops like this are state bugs wearing a backup costume. The verification itself works; the bookkeeping does not, so the scheduler honestly believes the snapshot is still pending. Because each iteration does real work and writes real logs, the run looks productive until someone reads identifiers instead of counts. Durable outcome state plus attempt caps make the failure mode impossible rather than unlikely.

Edge cases / pitfalls

• Idempotency keys per snapshot per run make duplicate submissions harmless even if selection glitches.
• Dashboards should show unique items completed, not total attempts. Attempt counts hide loops as productivity.
• Keep the loop detector even after the state bug is fixed. It is cheap insurance for the next state bug.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1C005VRhu3ro-Ti34d20nA