aaif-goose/goose · error

Resolved GGUF model has no local files

Error message

Resolved GGUF model has no local files

What it means

register_resolved_model destructures ResolvedLocalModel::Gguf and requires local_paths.first() to exist. local_paths is built one-per-file in download_gguf_to_hf_cache, and resolve_model_spec_full already bails when no GGUF matches, so an empty local_paths means an invariant was violated: a Gguf value was constructed with zero local files (programmatic misuse or an upstream bug), not a network failure.

Source

Thrown at crates/goose-local-inference/src/hf_models.rs:2380

pub fn register_resolved_model(resolved: ResolvedLocalModel, source: &str) -> Result<String> {
    let model_id = resolved.model_id();
    let repo_id = resolved.repo_id().to_string();
    let variant_id = resolved.variant_id().to_string();
    let backend_id = resolved.backend_id().to_string();
    let storage = resolved.storage();

    let entry = match resolved {
        ResolvedLocalModel::Gguf {
            resolved,
            local_paths,
            mmproj_path,
            ..
        } => {
            let first_file = &resolved.files[0];
            let first_local_path = local_paths
                .first()
                .cloned()
                .ok_or_else(|| anyhow::anyhow!("Resolved GGUF model has no local files"))?;
            let shard_files: Vec<ShardFile> = resolved
                .files
                .iter()
                .skip(1)
                .zip(local_paths.iter().skip(1))
                .map(|(file, local_path)| ShardFile {
                    filename: file.filename.clone(),
                    local_path: local_path.clone(),
                    source_url: file.download_url.clone(),
                    size_bytes: file.size_bytes,
                })
                .collect();
            let settings = super::local_model_registry::default_settings_for_model(&model_id);
            super::local_model_registry::LocalModelEntry {
                id: model_id.clone(),
                repo_id,
                filename: first_file.filename.clone(),
                quantization: variant_id,

View on GitHub (pinned to 3810898a74)

Solutions

1. Only register models produced by resolve_local_model_selection / resolve_gguf_model
2. If hit in production unexpectedly, capture the repo_id/quantization and report it as a bug - the invariant upstream of this point failed
3. Add a construction-time check (see validation) so misuse fails at the boundary with a clearer message

Example fix

// before
register_resolved_model(ResolvedLocalModel::Gguf { resolved, local_paths: vec![], .. }, source)?;

// after: fail at the boundary with a precise message
anyhow::ensure!(!local_paths.is_empty(), "GGUF model {repo_id} downloaded zero files");
register_resolved_model(ResolvedLocalModel::Gguf { resolved, local_paths, .. }, source)?;

if matches!(&resolved, ResolvedLocalModel::Gguf { local_paths, .. } if local_paths.is_empty()) {
    anyhow::bail!("refusing to register GGUF model with zero downloaded files");
}

fn gguf_has_local_files(resolved: &ResolvedLocalModel) -> bool {
    !matches!(resolved, ResolvedLocalModel::Gguf { local_paths, .. } if local_paths.is_empty())
}

match register_resolved_model(resolved, source) {
    Err(e) if e.to_string() == "Resolved GGUF model has no local files" => {
        // invariant failure upstream: log repo/variant and report a bug; do not retry
    }
    other => other,
}

When it happens

Trigger: Hand-constructing ResolvedLocalModel::Gguf with empty resolved.files or empty local_paths; a code path that registers a resolved model without going through the download step.

Common situations: Internal callers or tests building the enum directly; refactors that skip download_gguf_to_hf_cache; partial construction during error handling.

Related errors

• llama.cpp model '{}' is missing a quantization
• Model not found: {}
• Failed to acquire registry lock
• Model not found
• Invalid model spec '{}': expected format 'user/repo:quantiza

AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16). Data as JSON: /api/errors/113ba6a18c492af8. Report an issue: GitHub.