unslothai/unsloth · warning · SttModelIdError

'{model_id}' is still cancelling; try again in a moment.

Error message

'{model_id}' is still cancelling; try again in a moment.

What it means

Raised by the STT download manager when you request a download for a model whose previous download thread is still alive and flagged as cancelled. The manager refuses to join a cancelling run because doing so would silently download nothing, so it tells you to retry once the cancel finishes. It is a transient state guard, not a permanent failure.

Source

Thrown at studio/backend/core/inference/stt_sidecar.py:800

            return False, stderr
        detail = stderr.decode("utf-8", "replace").strip()
        raise SttModelCompatibilityError(f"Download worker failed for '{self._repo}': {detail}")

    def start(
        self,
        model_id: str,
        hf_token: Optional[str] = None,
        revision: Optional[str] = None,
    ) -> None:
        model_id = resolve_model_id(model_id)
        hub_cache = _capture_stt_hub_cache()
        with self._lock:
            if self._thread is not None and self._thread.is_alive():
                if self._model_id == model_id:
                    # Joining a cancelling run would silently download nothing.
                    if not self._cancelled:
                        return
                    raise SttModelIdError(
                        f"'{model_id}' is still cancelling; try again in a moment."
                    )
                raise SttModelIdError(
                    f"Another dictation model ('{self._model_id}') is still "
                    "downloading; wait for it to finish."
                )
            self._model_id = model_id
            self._repo = resolve_model_repo(model_id)
            self._revision = None
            self._hub_cache = hub_cache
            self._error = None
            self._total_bytes = None
            self._selected_files = ()
            self._complete = False
            self._cancelled = False
            self._process = None
            thread = threading.Thread(
                target = self._run,

View on GitHub (pinned to 203007d190)

Solutions

  1. Wait a moment and retry the same download call; the cancelling thread exits on its own and the next call proceeds.
  2. Poll or await the previous cancel completing (thread no longer alive) before issuing the new download request.
  3. In UI code, disable the Download button while a cancel for the same model is in flight instead of firing immediately.

Example fix

// before
downloader.cancel(model_id);
downloader.download(model_id);  // raises SttModelIdError
// after
downloader.cancel(model_id);
wait_until_thread_exits();  // or debounce the UI
downloader.download(model_id);
Defensive patterns

Strategy: retry

Validate before calling

with downloader._lock:
    busy = downloader._thread is not None and downloader._thread.is_alive() and downloader._cancelled
# only call download() when busy is False

Type guard

def is_cancel_in_flight(d) -> bool:
    with d._lock:
        return d._thread is not None and d._thread.is_alive() and d._cancelled

Try / catch

for attempt in range(5):
    try:
        downloader.download(model_id); break
    except SttModelIdError as e:
        if "still cancelling" not in str(e): raise
        time.sleep(0.5)

Prevention

When it happens

Trigger: Calling the download API for model X immediately after calling cancel on a download of the same model X, while the worker thread has not yet exited (self._thread.is_alive() and self._cancelled is True and self._model_id == model_id).

Common situations: A UI 'Cancel download' button followed quickly by 'Download again' for the same dictation model; rapid toggling between models in Settings; automated retry loops that cancel and restart downloads without waiting.

Related errors


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