## TL;DR
The experiment already exists, so reuse it instead of creating it: look it up by name with get_experiment_by_name and use its id, and only create when the lookup returns nothing. Creation scripts that run on every job start hit this the second time they run; make experiment setup idempotent and the error disappears.

```text
MLflow experiment creation failed with error 'RESOURCE_ALREADY_EXISTS: Experiment already exists'
```

## Use this when
- The run or call fails with this symptom: RESOURCE_ALREADY_EXISTS: Experiment already exists on creation.
- You are working on an MLflow setup script or training job that ensures an experiment exists 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 different experiments that should not share a name, where the fix is renaming one rather than reusing it.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Call get_experiment_by_name for the target name and record whether it returns an experiment and in what lifecycle stage. Verify: the existing experiment's id and stage are known
2. If it is active, use that id for the run instead of calling create_experiment. Verify: the job proceeds against the existing experiment
3. If it is deleted, restore it or pick a new name, since a deleted name still blocks creation. Verify: the name conflict is resolved explicitly
4. Wrap setup as ensure-experiment logic and rerun the job twice to prove idempotence. Verify: the second run reuses the experiment with no error

## Variant phrasings
### mlflow experiment already exists resource_already_exists
The verbatim phrasing.
### mlflow create_experiment name conflict deleted experiment
The deleted-name phrasing.
### mlflow experiment creation failed already exists fix
The fix phrasing.

Compatibility: MLflow 2.x and 3.x tracking servers, experiment management

## Why it happens
Experiment names are unique in the store, including names held by deleted experiments, so create is not an ensure operation. Any setup that runs more than once, retries, schedulers, shared notebooks, collides with its own earlier success.

## Edge cases / pitfalls
- Name matching is exact; trailing spaces in config values create near-duplicate experiments that look like conflicts.
- In multi-user servers, the existing experiment may belong to another team; check the owner before reusing it.

## Provenance

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