agent loop detected: deleting and recreating the same test VM repeatedly

TL;DR

Break the loop at the harness, not at the hypervisor. Compute a hash of everything that defines the test VM, the restore point, image, size, network, and script version, and before creating anything, look for an existing VM carrying that hash and reuse it if it is healthy. Count consecutive creations with the same hash, stop at three, and refuse another identical attempt until an input actually changes or an operator approves, recording the loop event with the hash and the attempt history.

agent loop detected: deleting and recreating the same test VM repeatedly

Use this when

• Cloud or hypervisor logs show the same test VM name created and deleted many times within one run or across retries.
• The restore test never reaches the verification stage, yet consumes its whole window provisioning.
• Each retry reports a slightly different surface error while the underlying spec never changes.

Not for this skill when

• A single VM creation fails once with a clear capacity or quota error.
• The test design intentionally creates a fresh VM per case in a matrix and the counts match the matrix size.

Steps

1. Hash the spec before creating. Build a canonical spec object for the test VM covering restore point id, image or snapshot, machine size, network placement, injected files, and test script version, sort its keys, and hash it. Store the hash on the run record and on the VM itself as a tag or label at creation time. Verify: two runs with the same inputs produce the same hash and a changed restore point produces a different one
2. Look before creating. Query the environment for a VM carrying the hash tag and a state of ready or running, and if one exists, attach to it, run a quick health check, and skip creation entirely. If one exists in a broken state, delete that one instance, record why, and count the recreation against the attempt budget for the hash. Verify: a second run with unchanged inputs reports reused rather than created
3. Install a circuit breaker on identical attempts. Keep a counter keyed by spec hash in the run store, increment it on each creation attempt, and block further creation at three consecutive attempts with the same hash and no successful verification between them. The block must survive agent restarts, so the counter lives in the store, not in memory. Verify: forcing a failing creation three times triggers the block and a fourth attempt is refused immediately
4. Require a change to reset the breaker. Unblock only when the spec hash changes, when a named input such as the restore point, image, or script is deliberately modified, or when an operator approves an override with a reason recorded. A retry timer expiring is not a change. On unblock, log which input changed. Verify: retrying with identical inputs stays blocked, and changing the test script version unblocks with the change logged
5. Diagnose the real failure while blocked. Use the blocked window to read the VM event log, the guest boot or serial output, and the provisioning error from the last attempt, and classify the root cause as capacity, image, network, or script. Surface that classification with the loop report rather than another blind creation. Verify: the loop report names a root cause category and quotes the last provisioning error
6. Clean up deliberately at run end. Delete the test VM only when the run completes or is abandoned by decision, not as part of the retry path, and keep one failed instance for inspection when the breaker trips if policy allows. Record total creations per hash in the run summary so loop behaviour is visible in routine reporting. Verify: the summary shows creations per spec hash and any hash over one is explained

Why it happens

Retry logic in agent harnesses usually treats a failed provisioning as transient and tries again, but the retry re-derives the same spec, so it recreates the identical VM and meets the identical failure. Deleting the evidence each time removes the boot logs that would explain the failure, so the loop is self-concealing. An input hash makes sameness visible to the harness, and a breaker converts an infinite loop into a single diagnosable stop.

Variants and edge cases

Edge cases: a spec that embeds a timestamp, random suffix, or session id will hash differently every time and defeat the breaker, so canonicalisation must strip volatile fields while keeping the VM name pattern recognisable. Legitimate fresh-VM-per-case matrices should key the counter per case id, not per whole run. If the environment cannot tag VMs, keep a registry mapping hash to instance id in the run store and reconcile it against a list call before creating.

agent created and deleted the same VM dozens of times

Use when provisioning churn dominates the logs. Add the spec hash and check for an existing matching VM first.

restore test loop with no verification ever running

Use when the run dies before the check stage every time. The breaker report should expose the repeated provisioning error.

test VM name keeps reappearing after deletion

Use when names repeat across retries. Count creations per hash in the run summary so the pattern is visible.

Provenance

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

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

Thread query: agent loop detected: deleting and recreating the same test VM repeatedly

TL;DR: Break the loop at the harness, not at the hypervisor. Compute a hash of everything that defines the test VM, the restore point, image, size, network, and script version, and before creating anything, look for an existing VM carrying that hash and reuse it if it is healthy. Count consecutive creations with the same hash, stop at three, and refuse another identical attempt until an input actually changes or an operator approves, recording the loop event with the hash and the attempt history.