unslothai/unsloth · warning · RuntimeError

A video load is already in progress.

Error message

A video load is already in progress.

What it means

Raised by begin_load when another video model load is already running (self._loading is set and its error is None). Video loads are heavyweight and single-slot; this RuntimeError enforces one load at a time. The state also claims companion asset repos under the same lock so a concurrent delete cannot pull a repo out from under an in-flight load.

Source

Thrown at studio/backend/core/inference/video.py:1340

        assert_video_precision_available(
            fam,
            model_kind = resolve_video_model_kind(gguf_filename, model_kind),
            transformer_quant = transformer_quant,
            text_encoder_quant = text_encoder_quant,
            gpu_ordinal = gpu_ordinal,
        )
        # Resolved out here so the companion claim is published in the SAME locked section as
        # _loading. begin_load returns as soon as the thread is scheduled, and a delete arriving in
        # that gap sees only repo_id and base_repo, passes the guard, and starts removing a
        # companion repo this load needs. A later claim does not revoke a delete already admitted.
        from .video_minimax_h3 import H3_COMPONENT_REPO, H3_GGUF_REPO, is_h3_native

        h3_native = is_h3_native(fam, resolve_video_model_kind(gguf_filename, model_kind))
        claimed_assets = (H3_GGUF_REPO, H3_COMPONENT_REPO) if h3_native else ()

        with self._lock:
            if self._loading is not None and self._loading.error is None:
                raise RuntimeError("A video load is already in progress.")
            self._load_token += 1
            token = self._load_token
            # A NEW event per load, never a clear() of the shared one: unload() sets the event the running worker holds but also
            # drops _loading, so the next begin_load would clear the object that worker watches. A fresh object leaves it set.
            cancel_event = threading.Event()
            self._cancel_event = cancel_event
            self._loading = _VideoLoadingState(
                repo_id = repo_id,
                base_repo = fam.base_repo,
                asset_repos = claimed_assets,
            )

        threading.Thread(
            target = self._run_load,
            kwargs = dict(
                repo_id = repo_id,
                gguf_filename = gguf_filename,
                base_repo = base_repo,

View on GitHub (pinned to 203007d190)

Solutions

  1. Wait for the in-flight load to finish (poll status) before issuing another.
  2. Cancel or unload the current load first, then begin the new one.
  3. Frontend: disable the Load button while the loading state is active.

Example fix

# before
begin_load(...)  # user double-clicks -> second call raises

# after
status = video.status()
if status.loading:
    video.cancel() or wait(status)
begin_load(...)
Defensive patterns

Strategy: try-catch

Validate before calling

with backend._lock:
    busy = backend._loading is not None and backend._loading.error is None
if busy:
    wait_or_cancel()  # instead of calling begin_load again

Try / catch

try:
    backend.begin_load(...)
except RuntimeError as e:
    if str(e) == 'A video load is already in progress.':
        wait_for_load_completion()  # or cancel(), then retry
    else:
        raise

Prevention

When it happens

Trigger: Calling begin_load a second time while the first load thread is still running — double-click on Load in the UI, two API clients loading concurrently, or a retry fired before the previous load finished or failed.

Common situations: Impatient double-clicks; a frontend not disabling the load button while loading; parallel batch scripts against the same backend; a stuck/slow download making the user re-submit.

Related errors

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