zed-industries/zed · error · FileExistsError

run record already exists: {namespace}/{experiment_name}/{ru

Error message

run record already exists: {namespace}/{experiment_name}/{run_id}

What it means

Raised as FileExistsError by the Modal function create_run_record() when /data/runs/{namespace}/{experiment_name}/{run_id}/state.json already exists. The launch flow calls this synchronously (record_function.remote) before spawning the controller, so it is an intentional idempotency guard: a launch aborts before any compute if its run id collides with an existing run on the volume.

Source

Thrown at crates/eval_cli/zed_eval/modal_app.py:642

@app.function(
    image=controller_image,
    cpu=1,
    memory=512,
    timeout=300,
    volumes={"/data": volume},
)
def create_run_record(run_request: dict[str, Any]) -> dict[str, Any]:
    namespace = run_request["namespace"]
    experiment_name = run_request["experiment_name"]
    run_id = run_request["run_id"]
    run_dir = pathlib.Path("/data/runs") / namespace / experiment_name / run_id
    state_path = run_dir / "state.json"

    reload_volume()

    if state_path.exists():
        raise FileExistsError(
            f"run record already exists: {namespace}/{experiment_name}/{run_id}"
        )

    run_dir.mkdir(parents=True, exist_ok=True)
    write_run_inputs(run_dir, run_request)
    state = {
        "run_id": run_id,
        "namespace": namespace,
        "experiment_name": experiment_name,
        "status": "pending",
        "created_at": run_request.get("created_at"),
        "updated_at": utc_now(),
        "build_id": run_request.get("build_id"),
    }
    write_json(state_path, state)
    volume.commit()
    return state

View on GitHub (pinned to bc538def45)

Solutions

1. Use a different --run-id (or drop the flag to let it auto-generate a unique timestamped id).
2. If you truly want to redo the run under the same id, delete the old record on the volume (/data/runs/<ns>/<experiment>/<run_id>) — but prefer keeping history and using a new id.
3. If the existing run is still healthy, just monitor it (zed-eval status <run_id>) instead of relaunching.

Example fix

# before
zed-eval run rf --run-id fixed-id   # second invocation
# -> FileExistsError: run record already exists: me/swe-atlas-rf/fixed-id

# after
zed-eval run rf --run-id fixed-id-2   # or omit --run-id entirely

# Prefer unique ids in wrappers; only pin --run-id if you also handle collisions:
run_id = args.run_id or f"{utc_timestamp()}-{uuid.uuid4().hex[:6]}"  # what the CLI does by default

try:
    record_state = record_function.remote(run_request)
except FileExistsError:
    # idempotency guard: reuse a fresh id (or inspect the existing run instead)
    run_request["run_id"] = f"{run_request['run_id']}-{uuid.uuid4().hex[:6]}"
    record_state = record_function.remote(run_request)

When it happens

Trigger: Re-launching with the same explicit --run-id (explicit ids are used verbatim for the first leg); retrying a launch whose controller already started (the record exists even if the controller later died); two operators using the same run id under the same namespace/experiment. Auto-generated ids (timestamp+uuid) effectively never collide.

Common situations: Pinned --run-id values in CI that rerun on retry; re-running a scripted launch after a partial failure; deliberately reusing a memorable id for a re-run.

Related errors

• choose at least one benchmark to run
• unknown benchmark '{benchmark_id}' (valid: {valid})
• unknown benchmark '{selector}' (valid: {valid})
• could not locate run '{run_id}' in the local run index ({run
• unknown judge preset '{name}' (valid: {valid})

AI-assisted analysis of zed-industries/zed@bc538def45 (2026-08-16). Data as JSON: /api/errors/efe4f894a11d3874. Report an issue: GitHub.