unslothai/unsloth · info · RuntimeError

Video generation was cancelled.

Error message

Video generation was cancelled.

What it means

Cancel notification raised at the first checkpoint of the H3 native (stable-diffusion.cpp) load worker, before the multi-GB download: if the load's cancel_event is already set when the worker starts (or reaches this point), it aborts immediately with the shared VIDEO_CANCELLED_MSG. This ordering exists so a cancel issued during install/setup does not still pay for the model download.

Source

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

        # pulls from both, and neither is repo_id or base_repo. loaded_repo_ids() is the committed
        # twin; expected_bytes stays below, where the sizes are known.
        # begin_load publishes the same claim with _loading, covering the gap before this thread is
        # scheduled. This one is for load_pipeline, which never goes through begin_load.
        with self._lock:
            if self._load_token == token and self._loading is not None:
                self._loading.base_repo = fam.base_repo
                self._loading.asset_repos = (H3_GGUF_REPO, H3_COMPONENT_REPO)

        # BEFORE the download, not after it. The H3-gated ensure, not the plain one: a build that
        # predates H3 runs fine and so clears the version() gate below, then aborts on the first
        # generation. That is the whole reason this gate exists, and running it after the four-file
        # bundle had already been fetched meant the user still paid tens of GB to be told no.
        #
        # Cancel first, though: the ensure below may download and extract the sd-cli prebuilt, and
        # it takes no cancel_event, so a load cancelled before this thread got going would pay for
        # an install nobody is waiting for. The download loop used to be the first check.
        if cancel_event.is_set():
            raise RuntimeError(VIDEO_CANCELLED_MSG)
        target = self._device_target(gpu_ordinal)
        allow_install = _install_allowed()
        binary = ensure_h3_sd_cpp_binary(
            allow_install = allow_install,
            accelerator = _install_accelerator_for(target.backend),
        )
        native_device = target.device
        # What the accelerator decision below was made on, or None when it was never asked (a CPU
        # or MPS target never consults it). Re-checked under the reader claim, so a replacement
        # that arrives mid-load cannot silently change the answer this device choice rests on.
        listed_accelerator: Optional[bool] = None
        if target.backend not in ("cpu", "mps"):
            # Under the claim, like the recheck. This probe SPAWNS the managed sd-cli, so leaving
            # it unclaimed lets an install started by another in-process load extract over the
            # executing binary: on Windows that fails on the locked file, on Linux it can leave
            # the replacement half-written. The later claimed recheck cannot undo damage this
            # first probe already allowed.
            from .sd_cpp_backend import _tree_reader as _claim_tree

View on GitHub (pinned to 203007d190)

Solutions

  1. No fix needed if the cancel was intended — this is the expected cancellation signal.
  2. If the cancel was accidental, simply start the load again.
  3. Client code should treat this message as a normal cancellation outcome, not an error to alert on.
Defensive patterns

Strategy: try-catch

Try / catch

try:
    run_h3_load(...)
except RuntimeError as e:
    if str(e) == VIDEO_CANCELLED_MSG:
        return Cancelled()  # expected outcome of cancel(); not an error
    raise

Prevention

When it happens

Trigger: begin_load for a MiniMax-H3 native GGUF load returns, then cancel/unload is called before or while the worker thread is starting — the worker sees cancel_event.is_set() at this first check and raises RuntimeError(VIDEO_CANCELLED_MSG).

Common situations: User clicks Load then immediately Cancel/Unload; an orchestration layer rolling back a load; switching models in rapid succession.

Related errors


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