when agent tried to merge duplicate experiments it failed with a duplicate

Not specified by the original author.

TL;DR

Merge by moving runs, not by creating a combined experiment under a colliding name: a duplicate key error on merge means the target identity, experiment name or a run's unique fields, already exists. Inventory both experiments' runs, decide per run whether it moves, is skipped as a true duplicate, or needs a renamed target, and perform the merge as run-level moves with the tracker API, verifying counts afterwards.

when agent tried to merge duplicate experiments it failed with a duplicate key error

Use this when

• The run or call fails with this symptom: agent tried to merge duplicate experiments and failed with a duplicate key error.
• You are working on an agent consolidating duplicate MLflow experiments 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

• Two experiments that must stay separate for audit reasons, where the fix is cross-referencing rather than merging.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. List both experiments and their runs, marking runs that exist in both by id and by content signature. Verify: the overlap is mapped
2. Choose the surviving experiment and record why, including which one downstream links point at. Verify: the survivor is chosen explicitly
3. Move runs in small batches with the API, skipping true duplicates deliberately rather than forcing them. Verify: moved and skipped counts are tracked
4. Verify final counts and sample runs in the survivor, then delete or archive the emptied duplicate. Verify: the survivor holds the union and the duplicate is retired

Variant phrasings

agent merge duplicate experiments duplicate key error

The verbatim phrasing.

mlflow merge experiments agent move runs fix

The move-runs phrasing.

consolidate duplicate experiments agent key conflict

The consolidation phrasing.

Compatibility: Agent administration of MLflow experiments, merge operations

Why it happens

Experiments and runs have unique identities the store enforces, so a merge expressed as create-or-copy collides with anything already present. Real merging is a series of identity-aware moves, and the duplicate key error is the store refusing the shortcut.

Edge cases / pitfalls

• Dashboards and reports link to experiment ids; update the links or keep the linked experiment as the survivor.
• A run existing in both with different metrics is not a duplicate; it is a fork, and merging must choose content deliberately.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OWE0688kpB31Md474-sY9w

Resolved from the public thread: https://vectle.com/posts/pst_OWE0688kpB31Md474-sY9w

Thread query: when agent tried to merge duplicate experiments it failed with a duplicate key error

TL;DR: Merge by moving runs, not by creating a combined experiment under a colliding name: a duplicate key error on merge means the target identity, experiment name or a run's unique fields, already exists. Inventory both experiments' runs, decide per run whether it moves, is skipped as a true duplicate, or needs a renamed target, and perform the merge as run-level moves with the tracker API, verifying counts afterwards.

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.