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

SttModelIdError raised in the mtmd downloader's start routine: a download thread for the SAME model_id is still alive and its _cancelled flag is set — i.e. a cancel was requested but the thread has not finished unwinding yet. Joining it would make the caller wait on a run that will download nothing, so the request is bounced instead. The wording is misleading: it means 'cancel still in progress', not a bad model id.

Source

Thrown at studio/backend/core/inference/stt_mtmd_sidecar.py:404

            )
            return min(done, total) if total is not None else done
        except Exception:
            return None

    def start(
        self,
        model_id: str,
        hf_token: Optional[str] = None,
    ) -> None:
        model_id = resolve_mtmd_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._error = None
            self._total_bytes = None
            self._selected_files = ()
            self._revision = None
            self._hub_cache = hub_cache
            self._cancelled = False
            self._process = None
            thread = threading.Thread(
                target = self._run,
                args = (model_id, hf_token),
                daemon = True,

View on GitHub (pinned to 203007d190)

Solutions

  1. Retry after a short delay — the old thread exits once its cancel path completes.
  2. In the UI, disable the Download button while a cancel is pending instead of allowing the immediate re-request.
  3. Poll the downloader state until no thread is alive before restarting the download.
Defensive patterns

Strategy: retry

Validate before calling

with downloader._lock:  # prefer a public status accessor if exposed
    busy = downloader._thread is not None and downloader._thread.is_alive()
    cancelling = busy and downloader._cancelled
if cancelling:
    wait_then_retry(model_id)

Try / catch

try:
    downloader.download(model_id)
except SttModelIdError as exc:
    if "still cancelling" in str(exc):
        time.sleep(0.5)
        downloader.download(model_id)

Prevention

When it happens

Trigger: Calling download(model_id) for model X, then immediately calling download(X) again after cancelling the first: self._thread.is_alive() and self._cancelled are both True.

Common situations: Rapid cancel-then-restart of a download in the Settings UI; double-click on Download after clicking Cancel; cancel fired but the HF download thread is still in its teardown.

Related errors


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