{"record":{"id":"7fee3e8280214f72","repo":"aaif-goose/goose","slug":"failed-to-acquire-registry-lock-7fee3e","errorCode":null,"errorMessage":"Failed to acquire registry lock","messagePattern":"Failed to acquire registry lock","errorType":"exception","errorClass":null,"httpStatus":null,"severity":"error","filePath":"crates/goose-local-inference/src/hf_models.rs","lineNumber":2448,"sourceCode":"                quantization: variant_id,\n                local_path: snapshot_path,\n                source_url: source.to_string(),\n                backend_id: Some(backend_id),\n                storage,\n                settings,\n                size_bytes: total_size,\n                mmproj_path: None,\n                mmproj_source_url: None,\n                mmproj_size_bytes: 0,\n                mmproj_checked: true,\n                shard_files: vec![],\n            }\n        }\n    };\n\n    let mut registry = get_registry()\n        .lock()\n        .map_err(|_| anyhow::anyhow!(\"Failed to acquire registry lock\"))?;\n    registry.add_model(entry)?;\n    Ok(model_id)\n}\n\nfn update_download_manager_progress(\n    model_id: &str,\n    bytes_downloaded: u64,\n    total_bytes: u64,\n    speed_bps: Option<u64>,\n) {\n    crate::download_manager::get_download_manager().update_progress(\n        &format!(\"{}-model\", model_id),\n        |progress| {\n            if progress.status == crate::download_manager::DownloadStatus::Cancelled {\n                return;\n            }\n            progress.bytes_downloaded = bytes_downloaded;\n            progress.total_bytes = total_bytes;","sourceCodeStart":2430,"sourceCodeEnd":2466,"githubUrl":"https://github.com/aaif-goose/goose/blob/3810898a7447ec3299be72e223d3570a7aabf0ab/crates/goose-local-inference/src/hf_models.rs#L2430-L2466","documentation":"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.","triggerScenarios":"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.","commonSituations":"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.","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)"],"exampleFix":null,"handlingStrategy":"fallback","validationCode":null,"typeGuard":null,"tryCatchPattern":"match register_resolved_model(resolved, source) {\n    Err(e) if e.to_string() == \"Failed to acquire registry lock\" => {\n        // registry mutex poisoned by an earlier panic: surface 'please restart',\n        // and schedule a fresh-process retry; in-process recovery is not possible here\n    }\n    other => other,\n}","preventionTips":["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"],"tags":["rust","concurrency","mutex","poisoning","registry","panic"],"backgroundTag":null,"analyzedSha":"3810898a7447ec3299be72e223d3570a7aabf0ab","analyzedAt":"2026-08-16T10:14:26.282Z","schemaVersion":2},"datasetVersion":"2026-08-16T13:17:31.715Z"}