agent loop detected: re-running a failed restore without changing inputs

TL;DR

Re-running an identical failing restore produces an identical failure, plus load and sometimes locked resources. Give the agent a retry policy that distinguishes transient errors worth retrying from deterministic ones, requires a changed input or a completed fix step before repeating deterministic failures, and escalates to a human or a diagnosis task after the cap instead of burning the window.

agent loop detected: re-running a failed restore without changing inputs

Use this when

• Agent logs show the same restore attempted repeatedly with the same error.
• Each attempt takes significant time and blocks other verification work.
• No diagnostic step happens between attempts.

Not for this skill when

• Retries with backoff succeed on transient network errors. That is healthy retry behaviour.
• A restore is repeated deliberately after an operator fixes storage. Changed input, intended.

Steps

1. Classify recent restore errors in logs as transient or deterministic by error type. Verify: each repeated failure is classified
2. Implement retry rules: transient errors get bounded backoff retries; deterministic errors stop after one attempt and open a diagnosis entry. Verify: a simulated deterministic failure stops after one run
3. Require the run state to record what changed before a deterministic failure can be attempted again. Verify: an unchanged retry request is refused by the agent
4. Route capped failures to the alerting path with full context. Verify: an escalation is created in a test
5. Run the verification suite with a seeded bad snapshot. Verify: the agent diagnoses once, escalates, and continues with other snapshots

Variant phrasings

agent retry deterministic failure no change loop

The policy phrasing.

failed restore repeated identical attempts stop

The symptom variant.

retry policy transient vs deterministic errors agent

The classification wording.

Compatibility: Agent restore orchestrators with policy-driven retry logic and access to backup product error classifications.

Why it happens

Naive retry logic treats every failure as weather: wait and try again. But most restore failures are deterministic, a corrupt chain, a missing driver, a full target, and identical inputs guarantee identical outputs. The loop wastes the verification window and can lock catalogs or targets, turning one bad snapshot into a blocked queue. Classification and change-gating are the fix.

Edge cases / pitfalls

• Some errors are transient only sometimes, such as timeouts under load. Cap their retries too and record load context.
• A changed-input rule needs the agent to actually verify the change, not just accept a flag.
• Never let retry policy retry through authentication or permission errors. Those need humans.

Provenance

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