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
- Scan logs above this error for the panic that poisoned the lock and fix that root cause
- Restart the process to reset the registry state, then retry the operation
- 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
- Never unwrap/expect while holding the registry lock; return Results instead
- Log panics loudly so the poison cause is diagnosable when this message appears
- Design long-running hosts to restart cleanly and re-read the registry from disk
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
- Failed to acquire registry lock
- Failed to acquire registry lock
- Failed to lock transcriber: {}
- goose-cli main thread panicked
- Failed to acquire lock
AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16).
Data as JSON: /api/errors/7fee3e8280214f72.
Report an issue: GitHub.