unslothai/unsloth · warning · HTTPException

Dataset not found in cache

Error message

Dataset not found in cache

What it means

HTTP 404 raised when a delete-dataset-cache request completed without any location reporting that it actually deleted or purged something. All outcome flags (deleted, processed_deleted, app_deleted, cache_purged, partial_purged, state_purged) were false, meaning no cache location knew about this repo_id. It is the 'nothing to delete' sentinel, not a failure.

Source

Thrown at studio/backend/hub/services/datasets/cache_inventory.py:665

    # ``scan_cache_dir()`` skips blob-only/corrupt repos the revision delete can't touch, yet the
    # fallback scanner shows them, so purge the whole dir. Hub cache targets only.
    cache_purged = partial_purged = state_purged = False
    if target_root is not None:
        cache_purged = purge_repo_cache_dirs("dataset", repo_id, root = target_root)
        partial_purged = purge_partial_repo("dataset", repo_id, root = target_root)
        state_purged = (
            download_manifest.purge_all_state_for_repo("dataset", repo_id, hub_cache = target_root)
            > 0
        )
    if not (
        deleted
        or processed_deleted
        or app_deleted
        or cache_purged
        or partial_purged
        or state_purged
    ):
        raise HTTPException(status_code = 404, detail = "Dataset not found in cache")
    return {"status": "deleted", "repo_id": repo_id}


def _delete_processed_dataset_cache(
    repo_id: str, only_roots: Optional[set[Path]] = None
) -> tuple[bool, list[str]]:
    import shutil

    target = repo_id.replace("/", "___")
    folded_target = target.lower()
    deleted = False
    failures: list[str] = []
    for root in _hf_datasets_cache_roots():
        # Scope to the selected cache's datasets root(s) so copies under other cache homes survive.
        if only_roots is not None and root.resolve(strict = False) not in only_roots:
            continue
        try:
            entries = [

View on GitHub (pinned to 203007d190)

Solutions

1. Treat 404 on delete as idempotent success if the goal is 'make sure it is gone'.
2. Verify the exact repo_id string (including owner prefix and case) matches what the cache inventory endpoint reports.
3. List cache entries first (the cache inventory endpoint) to confirm the dataset is actually present before deleting.
4. If the UI still shows it, refresh the inventory — the listing likely came from a stale response.

Example fix

// before
deleteDatasetCache(repoId); // throws on 404
// after
try { await deleteDatasetCache(repoId); }
catch (e) { if (e.status !== 404) throw e; /* already gone */ }

resp = list_cache_inventory(client)
known = {e.repo_id for e in resp.entries}
if repo_id not in known:
    skip_delete()  # nothing to delete; avoids the 404 round trip

try:
    delete_dataset_cache(client, repo_id)
except HTTPStatusError as e:
    if e.response.status_code == 404:
        pass  # already gone — treat as success (idempotent delete)
    else:
        raise

When it happens

Trigger: Calling delete for a repo_id never downloaded, a repo_id whose case differs from the cached directory name (before case canonicalization), or re-sending a delete request that already succeeded.

Common situations: Frontend fires the delete twice (double-click or retry after a timeout); user typed the dataset name with different casing; the cache was cleared out-of-band while the UI still listed the dataset.

Related errors

• dataset_local_cache_miss
• Unsupported transformer_cache '{value}'. Use one of: off, au
• Authorization callback was already used.
• STT model '{model_id}' is not downloaded. Download it in Set
• Multiple cached {noun} differ only by case. Delete the exact

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