unslothai/unsloth · error · RuntimeError

pinned release {pin_release_tag} but installer produced {new

Error message

pinned release {pin_release_tag} but installer produced {new_tag}

What it means

Narrower sibling of the repo-preservation check: it fires only when no backend_request was supplied (a plain update, not a switch), a release tag was pinned, the installer did record a tag, and the repo is unchanged — but the installed tag differs from the pin. I.e. the install succeeded yet landed on the wrong release of the right repository.

Source

Thrown at studio/backend/utils/llama_cpp_update.py:678

        try:
            latest_published_release(repo, force_refresh = True)
        except Exception as exc:  # pragma: no cover - network defensive
            logger.debug("llama update: post-install freshness refresh failed", error = str(exc))
        new_marker = read_install_marker(_find_binary())
        new_tag = (new_marker or {}).get("release_tag") or (new_marker or {}).get("tag")
        new_backend = marker_backend(new_marker)
        new_backend_request = marker_backend_request(new_marker)

        new_repo = (new_marker or {}).get("published_repo")
        if pin_release_tag and backend_request is not None:
            if new_repo != repo or new_tag != pin_release_tag:
                raise RuntimeError(
                    "backend switch must preserve "
                    f"{repo}@{pin_release_tag}, but installer produced "
                    f"{new_repo or 'an unknown repository'}@{new_tag or 'an unknown release'}"
                )
        elif pin_release_tag and new_tag and new_repo == repo and new_tag != pin_release_tag:
            raise RuntimeError(f"pinned release {pin_release_tag} but installer produced {new_tag}")

        if backend_request is not None:
            if new_backend is None:
                raise RuntimeError(
                    f"requested {backend_request} but the installed backend is unknown"
                )
            if new_backend_request != backend_request:
                raise RuntimeError(
                    f"requested {backend_request} but the installer recorded "
                    f"{new_backend_request or 'an unknown selection'}"
                )
            if backend_request != "auto" and new_backend != backend_request:
                raise RuntimeError(
                    f"requested {backend_request} but the installer produced "
                    f"{new_backend or 'an unknown backend'}"
                )

        logger.info("llama update: success", to_tag = new_tag, backend = new_backend)

View on GitHub (pinned to 203007d190)

Solutions

  1. Confirm the pinned tag publishes an artifact for your OS/arch and re-run
  2. If you intended to track latest, drop the pin_release_tag argument
  3. Re-pin to the tag actually installed if that release is acceptable
  4. Clear the managed install and re-run with the pin so no stale marker confuses the check

Example fix

# before
run_update(pin_release_tag='b1234')
# RuntimeError: pinned release b1234 but installer produced b4900

# after
run_update(pin_release_tag='b4900')  # or omit the pin to track latest
Defensive patterns

Strategy: validation

Validate before calling

from utils.llama_cpp_update import latest_published_release

def tag_exists(repo: str, tag: str) -> bool:
    try:
        return tag == getattr(latest_published_release(repo, force_refresh=True), 'tag', None)
    except Exception:
        return False  # do not block on network; rely on the post-check

Try / catch

try:
    run_update(pin_release_tag=tag)
except RuntimeError as exc:
    if 'pinned release' in str(exc):
        run_update(pin_release_tag=parse_installed_tag(exc))  # accept reality or re-pin
    else:
        raise

Prevention

When it happens

Trigger: run_update(pin_release_tag='b1234') without backend_request, where read_install_marker returns the same published_repo but a different tag — e.g. the pinned tag had no artifact for the platform and the installer fell back to the closest release, or the pin was overridden by a 'latest' policy.

Common situations: Platform-specific asset missing for the pinned release (macOS arm64 vs x86 asset naming); user pinned an old tag while auto-update logic prefers latest; concurrent runs where one pinned and the other updated freely.

Related errors

AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15). Data as JSON: /api/errors/7f73ffc45d61b509. Report an issue: GitHub.