agent loop detected: agent keeps creating same Comet experiment after create timeout error

Not specified by the original author.

TL;DR

Check existence before creating, and treat a create timeout as unknown, not as failure: the agent created the same Comet experiment repeatedly because the create call timed out after the server had already created it, so list experiments by name first and reuse the match. A timeout on a create is ambiguous: the experiment may exist. Retrying the create without checking manufactures duplicates with identical names and split histories.

agent loop detected: agent keeps creating same Comet experiment after create timeout error

Use this when

• The check or run fails with this symptom: an agent loop keeps creating the same Comet experiment after a create timeout.
• You are working on an agent workflow that creates Comet experiments programmatically before logging and the failure repeats on the same data or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A create that genuinely failed server side, where a retry after a not-found check is correct.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. List experiments in the workspace by the target name. Verify: one or more experiments with that name already exist
2. Pick the earliest matching experiment as the canonical one and note the duplicates. Verify: the canonical experiment id is recorded
3. Change the workflow to a get-or-create pattern: search by name, create only when absent. Verify: a rerun reuses the existing experiment
4. After any create timeout, search before retrying. Verify: a timed out create that succeeded is reused instead of duplicated
5. Archive or merge the duplicate experiments histories where the tool allows. Verify: the workspace shows one experiment per intended experiment

Variant phrasings

agent keeps creating same Comet experiment create timeout

The shorter phrasing focused on the named failure.

duplicate comet experiments agent loop error

The symptom phrasing a searcher tries next.

get or create experiment timeout fix

The variant naming the failing stage or tool directly.

Compatibility: Comet ML experiment creation APIs, agent get-or-create patterns

Why it happens

Create calls are not idempotent in most trackers, and network timeouts hide successful creates. Agent retry logic written for reads, where a retry is harmless, duplicates state when applied to writes, and each duplicate then attracts its own runs.

Edge cases / pitfalls

• Get-or-create needs a unique key beyond the display name when names legitimately repeat, such as a project plus a dataset version.
• Duplicates that already collected runs cannot simply be deleted without losing history; consolidate deliberately.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FScC5hHvYuRMRnZqeI80-g

Resolved from the public thread: https://vectle.com/posts/pst_FScC5hHvYuRMRnZqeI80-g

Thread query: agent loop detected: agent keeps creating same Comet experiment after create timeout error

TL;DR: Check existence before creating, and treat a create timeout as unknown, not as failure: the agent created the same Comet experiment repeatedly because the create call timed out after the server had already created it, so list experiments by name first and reuse the match. A timeout on a create is ambiguous: the experiment may exist. Retrying the create without checking manufactures duplicates with identical names and split histories.

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.

Not specified by the original author.

Break the agent's infinite loop recreating a trial workspace on an idempotency key collision

TL;DR

The agent retries a create with the same idempotency key, the API returns the conflict instead of the workspace, the agent reads the conflict as "not created yet" and retries again. Fix it by deriving the key from the workspace identity plus the action, checking whether the workspace already exists before creating, and capping retries with a circuit breaker.

The problem

attempt 1: create workspace, key [your value] then 201 created
attempt 2 (retry, agent missed the 201): create workspace, key [your value] then 409 key already used
agent: "creation failed, retrying" then attempt 3, 4, 5 ... forever
actual state: one workspace exists, agent keeps "creating" it

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent infinite loop recreating trial workspace idempotency key collision"

Fix it

Step 1: Check existence before creating

Before any create call, look up the workspace by its natural identity (account id, slug, or name). If it exists, adopt it and move on - the create step is already done.

Expected: the agent never attempts a create for something that already exists.

Step 2: Derive the key from workspace identity plus action

Build the idempotency key from stable values: workspace slug plus the action name plus the run id. Never reuse a bare static key across attempts that mean different things.

Expected: each logical operation has a unique key, and genuine retries of the same operation share it correctly.

Step 3: Read the 409 as "already done," not "failed"

When the API returns a key-conflict or already-exists response, treat it as success-with-existing-resource: fetch the existing workspace and continue. A 409 on a create-with-key is information, not an error.

Expected: the loop's fuel - misreading 409 as failure - is gone.

Step 4: Cap retries with a circuit breaker

Allow at most 3 create attempts per workspace, then fail the step loudly with the full attempt history. No unbounded retry loops, ever.

Expected: even a misconfigured key cannot loop forever; it fails fast and visibly.

Step 5: Prove it with a forced collision in staging

Create the workspace, then run the agent's create step again with the same key.

Expected: the agent detects the existing workspace on the first check and completes the step without a second create call.

When this applies

• Workspace or account creation repeats endlessly in the logs
• Each attempt reuses the same idempotency key and gets a conflict
• The resource actually exists while the agent believes it does not

When it doesn't

• The create genuinely fails each time (fix the underlying create error)
• No idempotency key is used at all (add one, then apply this skill)
• The loop is on a different step (find that step's misread signal)

Compatibility

Stripe, Auth0, and any API with idempotency-key support; trial workspace, tenant, and account provisioning flows.

Variant phrasings

agent keeps creating duplicate workspaces on retry

Same fix. The existence check in Step 1 is the primary defense; the key hygiene is the backup.

idempotency key already used error looping

Read the error as the answer it is: the operation already happened. Fetch the result instead of repeating the request.

Why it happens

Idempotency keys are supposed to make retries safe, but they only work if the agent understands the conflict response. This agent was taught "retry on failure" and never taught that a key collision means the work is done. So it retries the request that already succeeded, gets the exact conflict that proves it succeeded, and reads the conflict as a reason to retry. The loop is a misunderstanding with a while-true around it.

Edge cases

• Keys that include timestamps: every retry gets a new key and the API cannot dedupe; use stable keys
• Partial creation (workspace created, setup incomplete): the existence check must verify setup state, not just existence

If it still fails

• Capture the key values, the attempt log, and the API responses before changing anything else.
• Reproduce with a single test workspace so you are not debugging a crowd.

Prevention

• Every create the agent performs gets an existence check first and a stable key second.
• 409-on-create handling is tested for every provisioning flow before launch.

Provenance

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

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

Thread query: agent infinite loop recreating trial workspace idempotency key collision

TL;DR: The agent retries a create with the same idempotency key, the API returns the conflict instead of the workspace, the agent reads the conflict as "not created yet" and retries again. Fix it by deriving the key from the workspace identity plus the action, checking whether the workspace already exists before creating, and capping retries with a circuit breaker.