janhq/jan · error · LlamacppError
LlamacppError , message: " " }}
Error message
LlamacppError {{ code: {code:?}, message: "{message}" }} What it means
LlamacppError is the plugin's structured error type, carrying an ErrorCode discriminant, a human-readable message, optional details, and loader library names. It is thrown by any command or routine inside tauri-plugin-llamacpp that fails, and its Display renders code and message so the frontend can branch on code. It exists so all plugin failures funnel into one serializable shape for Tauri IPC.
Solutions
- Read the error's code field and match it against the ErrorCode enum to identify the failing subsystem.
- Inspect message and details for the underlying cause; check library_names if loader errors are reported.
- Fix the underlying condition (model path, library availability, config) rather than catching generically.
- Forward the structured error to the UI so it can render a code-specific message.
Example fix
// before: treating every failure the same
if let Err(e) = start_server(app, model) { eprintln!("failed: {}", e); }
// after: branch on the structured code
match start_server(app, model) {
Err(e) if e.code == ErrorCode::IoError => eprintln!("io: {}", e.message),
Err(e) => eprintln!("llamacpp {:?}: {}", e.code, e.message),
Ok(_) => {}
} Defensive patterns
Strategy: try-catch
Try / catch
match result {
Err(e) => handle_llamacpp_error(&e.code, &e.message, e.details.as_deref(), e.library_names.as_deref()),
Ok(v) => proceed(v),
} Prevention
- Always match on ErrorCode instead of string-matching messages.
- Surface library_names to the UI so missing shared libraries are actionable.
- Keep the error type serializable end-to-end so the frontend gets structure, not strings.
When it happens
Trigger: Any plugin operation that wraps a failure into LlamacppError::new(code, message): server start/stop failures, model download or load errors, process management failures, or loader resolution failures (which populate the library_names field).
Common situations: Missing or unloadable GGUF model files, llama.cpp shared libraries not found at runtime, server binary failing to spawn, or invalid model configuration passed from the UI.
Related errors
AI-assisted analysis of janhq/jan@7205d770c1 (2026-09-17).
Data as JSON: /api/errors/4c80c66e8db05645.
Report an issue: GitHub.
Appendix: source
Thrown at src-tauri/plugins/tauri-plugin-llamacpp/src/error.rs:25
ModelLoadFailed,
ModelArchNotSupported,
ModelLoadTimedOut,
MissingSharedLibrary,
GpuDriverTooOld,
// --- Memory Errors ---
OutOfMemory,
// --- Configuration Errors ---
InvalidArgument,
// --- Internal Application Errors ---
IoError,
InternalError,
}
#[derive(Debug, Clone, Serialize, thiserror::Error)]
#[error("LlamacppError {{ code: {code:?}, message: \"{message}\" }}")]
pub struct LlamacppError {
pub code: ErrorCode,
pub message: String,
#[serde(skip_serializing_if = "Option::is_none")]
pub details: Option<String>,
/// Library names the loader could not resolve, so the UI can turn them into
/// install advice instead of showing raw engine output.
#[serde(skip_serializing_if = "Option::is_none")]
pub missing_libraries: Option<Vec<String>>,
}
impl LlamacppError {
pub fn new(code: ErrorCode, message: String, details: Option<String>) -> Self {
Self {
code,
message,
details,
missing_libraries: None,View on GitHub (pinned to 7205d770c1)