aaif-goose/goose · error

Failed to acquire registry lock

Error message

Failed to acquire registry lock

What it means

get_registry() hands out a process-global Mutex-protected model registry; .lock() returning Err means the mutex is poisoned - another thread panicked while holding the registry lock. This message is the symptom; the original panic (visible earlier in logs) is the cause. Once poisoned, every subsequent registry operation from register_resolved_model fails the same way until the process restarts.

Source

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

                quantization: variant_id,
                local_path: snapshot_path,
                source_url: source.to_string(),
                backend_id: Some(backend_id),
                storage,
                settings,
                size_bytes: total_size,
                mmproj_path: None,
                mmproj_source_url: None,
                mmproj_size_bytes: 0,
                mmproj_checked: true,
                shard_files: vec![],
            }
        }
    };

    let mut registry = get_registry()
        .lock()
        .map_err(|_| anyhow::anyhow!("Failed to acquire registry lock"))?;
    registry.add_model(entry)?;
    Ok(model_id)
}

fn update_download_manager_progress(
    model_id: &str,
    bytes_downloaded: u64,
    total_bytes: u64,
    speed_bps: Option<u64>,
) {
    crate::download_manager::get_download_manager().update_progress(
        &format!("{}-model", model_id),
        |progress| {
            if progress.status == crate::download_manager::DownloadStatus::Cancelled {
                return;
            }
            progress.bytes_downloaded = bytes_downloaded;
            progress.total_bytes = total_bytes;

View on GitHub (pinned to 3810898a74)

Solutions

  1. Scan logs above this error for the panic that poisoned the lock and fix that root cause
  2. Restart the process to reset the registry state, then retry the operation
  3. If you own the code path, avoid panics inside the lock (no unwrap/expect while holding the guard)
Defensive patterns

Strategy: fallback

Try / catch

match register_resolved_model(resolved, source) {
    Err(e) if e.to_string() == "Failed to acquire registry lock" => {
        // registry mutex poisoned by an earlier panic: surface 'please restart',
        // and schedule a fresh-process retry; in-process recovery is not possible here
    }
    other => other,
}

Prevention

When it happens

Trigger: Any panic inside a registry critical section (unwrapped serde/fs/index error in add_model or a sibling op) followed by another register_resolved_model call in the same process.

Common situations: A corrupted registry JSON hitting an unwrap during load/save; a panic in enrichment logic (enrich_with_featured_mmproj); long-running desktop processes where one poisoned lock breaks all later model installs.

Related errors


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