Lockfile is out of date. Use one of these commands to regene

Error message

Lockfile is out of date. Use one of these commands to regenerate it:

uv run crates/ty_python_semantic/mdtest.py -e external/

Or using cargo:

MDTEST_EXTERNAL=1 MDTEST_UPGRADE_LOCKFILES=1 cargo test -p ty_python_semantic --test mdtest mdtest__external

What it means

setup_venv runs `uv sync --locked` against the committed lockfile. When uv reports that `uv.lock` needs to be updated but --locked was given, the committed lockfile is stale relative to the mdtest's declared dependencies, and the harness bails with regeneration instructions.

Source

Thrown at crates/ty_test/src/external_dependencies.rs:112

    let mut uv_sync = std::process::Command::new("uv");
    uv_sync
        .args(["sync", "--python-platform", uv_platform])
        .current_dir(temp_path.as_std_path());
    if use_locked {
        uv_sync.arg("--locked");
    }

    let uv_sync_output = uv_sync
        .output()
        .context("Failed to run `uv sync`. Is `uv` installed?")?;

    if !uv_sync_output.status.success() {
        let stderr = String::from_utf8_lossy(&uv_sync_output.stderr);

        if use_locked
            && stderr.contains("`uv.lock` needs to be updated, but `--locked` was provided.")
        {
            bail!(
                "Lockfile is out of date. Use one of these commands to regenerate it:\n\
                 \n\
                 uv run crates/ty_python_semantic/mdtest.py -e external/\n\
                 \n\
                 Or using cargo:\n\
                 \n\
                 MDTEST_EXTERNAL=1 MDTEST_UPGRADE_LOCKFILES=1 cargo test -p ty_python_semantic --test mdtest mdtest__external"
            );
        }

        bail!(
            "`uv sync` failed with exit code {:?}:\n{}",
            uv_sync_output.status.code(),
            stderr
        );
    }

    // In upgrade mode, copy the generated lockfile back to the source location

View on GitHub (pinned to 26f38c119c)

Solutions

Regenerate with `uv run crates/ty_python_semantic/mdtest.py -e external/`
Or run `MDTEST_EXTERNAL=1 MDTEST_UPGRADE_LOCKFILES=1 cargo test -p ty_python_semantic --test mdtest mdtest__external`, then commit the updated uv.lock
Diff the regenerated uv.lock to confirm only intended dependency changes

Example fix

// before (stale lockfile)
MDTEST_EXTERNAL=1 cargo test -p ty_python_semantic --test mdtest mdtest__external
// after
MDTEST_EXTERNAL=1 MDTEST_UPGRADE_LOCKFILES=1 cargo test -p ty_python_semantic --test mdtest mdtest__external
# commit the refreshed uv.lock, then re-run locked

Defensive patterns

Strategy: retry

Validate before calling

cd crates/ty_python_semantic/resources/mdtest/external && \
  uv lock --check || echo "lockfile stale: regenerate with MDTEST_UPGRADE_LOCKFILES=1"

Prevention

After editing external mdtest dependencies, always regenerate uv.lock and commit it
Run `uv lock --check` locally or in CI to detect staleness early
Pin the uv version used for lockfile generation to keep resolution stable

When it happens

Trigger: Running an external-dependency mdtest after the mdtest's dependency declarations (or uv version) changed so the committed uv.lock no longer satisfies `uv sync --locked`.

Common situations: Editing an external mdtest's dependencies without regenerating uv.lock; rebasing over a dependency bump; uv resolving requirements differently after a toolchain update.

Related errors

AI-assisted analysis of astral-sh/ruff@26f38c119c (2026-09-05). Data as JSON: /api/errors/88510becabc2f185. Report an issue: GitHub.