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
- Wait a moment and retry the same download call; the cancelling thread exits on its own and the next call proceeds.
- Poll or await the previous cancel completing (thread no longer alive) before issuing the new download request.
- 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
- Debounce the Download button after Cancel until the cancel completes
- Never join or reuse the download thread yourself; let the manager reach idle state
- Treat 'still cancelling' as transient state, never surface it as a hard failure
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
- '{model_id}' is still cancelling; try again in a moment.
- '{model_id}' is still cancelling; try again in a moment.
- Another dictation model ('{self._model_id}') is still downlo
- Another GGUF dictation model ('{self._model_id}') is still d
- The local transcription runtime is being updated. Try dictat
AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15).
Data as JSON: /api/errors/d907934cd9f9cd24.
Report an issue: GitHub.