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

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

Every test restore gets a unique name and its own lifecycle: reusing one name meant each run destroyed the previous test's evidence and, worse, could collide with a restore someone was still examining. Generate test VM names from the source, date, and a run identifier, record the mapping in the test log, and tear down by the run's own identifier only after its results are recorded.

agent overwrote the only test restore VM by reusing its name for the next verification run

Use this when

• The job or restore fails with this symptom: agent overwrote the only test restore VM by reusing its name for the next verification run.
• You are working on an agent running recurring restore verification tests and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A deliberately persistent golden test VM that the team maintains as a reference, which should be excluded from agent teardown by an explicit tag.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Review the test history and confirm the naming collision destroyed a prior test's target. Verify: the overwrite event is documented
2. Change naming to a generated unique form including source and run id, and store the name in the run record. Verify: each test has a unique, recorded target
3. Scope teardown to the run's own identifier and require results to be recorded before teardown is allowed. Verify: teardown cannot eat unrecorded evidence
4. Add a pre-create check that refuses a name that already exists instead of overwriting it. Verify: collisions refuse rather than destroy
5. Run two tests back to back and confirm both VMs coexist until their own teardowns. Verify: isolation holds across runs

Variant phrasings

agent overwrote test restore vm reused name next verification

The verbatim phrasing.

agent restore test unique naming teardown lifecycle fix

The lifecycle phrasing.

test restore vm name collision agent destroyed evidence

The collision phrasing.

Compatibility: Agent restore test isolation and test VM lifecycle management

Why it happens

Names are identity in virtualised estates, and a fixed test name turns a recurring verification into a single overwriting slot. The failure is not just lost evidence; a restore that lands on a name a human is using for diagnosis corrupts two processes at once.

Edge cases / pitfalls

• Orphaned test VMs from crashed runs accumulate; a janitor pass keyed on the naming pattern reclaims them safely.
• The unique name should sort by date so humans browsing the estate read the test history naturally.

Provenance

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

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

Thread query: agent overwrote the only test restore VM by reusing its name for the next verification run

TL;DR: Every test restore gets a unique name and its own lifecycle: reusing one name meant each run destroyed the previous test's evidence and, worse, could collide with a restore someone was still examining. Generate test VM names from the source, date, and a run identifier, record the mapping in the test log, and tear down by the run's own identifier only after its results are recorded.

Not specified by the original author.

TL;DR

Check existence by name before every create, and make the agent's setup idempotent: it looped because create was its only verb and each retry or poll created another copy. List experiments at startup, reuse the one that matches, and if creation is ever repeated, detect duplicates by name and converge on the oldest as canonical.

agent loop detected: agent created the same experiment repeatedly and failed to check existence error

Use this when

• The run or call fails with this symptom: agent loop detected: agent created the same experiment repeatedly and failed to check existence.
• You are working on an agent that ensures an experiment exists before logging runs and the failure repeats on the same run or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A design that legitimately creates one experiment per dataset version, where the fix is a naming scheme that makes the intent explicit rather than existence checks.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. List the experiments the agent created and group them by name to size the duplication. Verify: the duplicate set is counted
2. Insert a get-by-name check before creation in the agent's setup path and use the returned experiment when present. Verify: setup becomes read-first
3. Converge the duplicates: move runs to the canonical experiment and archive the copies. Verify: one experiment per name remains
4. Run the agent's setup twice and confirm the second run creates nothing. Verify: idempotence is proven by repetition

Variant phrasings

agent created same experiment repeatedly loop existence check

The verbatim phrasing.

agent loop duplicate experiments idempotent setup fix

The idempotence phrasing.

tracking server full of duplicate experiments agent created

The pile-up phrasing.

Compatibility: Agent loops creating experiments on tracking servers

Why it happens

Create-without-check is the default shape of generated setup code, and any loop or retry around it mints duplicates at machine speed. Tracking servers allow same-named or suffixed creations readily, so the pile grows until a human notices the experiment list.

Edge cases / pitfalls

• Near-duplicate names with timestamps or suffixes are the same bug in a trench coat; group by normalised name.
• Cleanup needs care: runs may be spread across the copies, so converge runs before deleting any copy.

Provenance

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

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

Thread query: agent loop detected: agent created the same experiment repeatedly and failed to check existence error

TL;DR: Check existence by name before every create, and make the agent's setup idempotent: it looped because create was its only verb and each retry or poll created another copy. List experiments at startup, reuse the one that matches, and if creation is ever repeated, detect duplicates by name and converge on the oldest as canonical.