jlcodes99/cockpit-tools · info
[Updater] {}
Error message
[Updater] {} What it means
The update_log command receives a log message and level from the frontend, prefixes it with '[Updater] ', and routes it to the appropriate logger (log_error/log_warn/log_info); it returns Ok(()) unless the message is empty (early return). The shown message '[Updater] {}' is the format template of every frontend-relayed updater log line, not a thrown error itself.
Source
Thrown at src-tauri/src/commands/update.rs:145
pub fn get_release_history(
locale: Option<String>,
limit: Option<usize>,
) -> Result<Vec<ReleaseHistoryItem>, String> {
update_checker::get_release_history(locale.as_deref(), limit)
}
/// Write updater lifecycle logs from frontend into app.log
#[tauri::command]
pub fn update_log(level: String, message: String) -> Result<(), String> {
let level = level.trim().to_lowercase();
let message = message.trim();
if message.is_empty() {
return Ok(());
}
let text = format!("[Updater] {}", message);
match level.as_str() {
"error" => logger::log_error(&text),
"warn" | "warning" => logger::log_warn(&text),
_ => logger::log_info(&text),
}
Ok(())
}
#[tauri::command]
pub fn get_update_runtime_info() -> Result<UpdateRuntimeInfo, String> {
Ok(linux_updater::get_update_runtime_info())
}
#[tauri::command]
pub async fn install_linux_update(
app: tauri::AppHandle,
expected_version: Option<String>,
) -> Result<(), String> {
linux_updater::install_linux_update(app, expected_version).awaitView on GitHub (pinned to 1ed8b77992)
Solutions
- Look at the text after '[Updater] ' for the real frontend-reported updater failure.
- Check frontend updater code that calls invoke('update_log', ...) to see the originating condition.
- If logs are missing entirely, verify the frontend passes a non-empty message, since empty messages are dropped.
- Match the level string exactly ('error', 'warn'/'warning') — other values are demoted to info logs.
Defensive patterns
Strategy: validation
Validate before calling
// Frontend: validate before invoking update_log
function safeUpdateLog(message: string, level: string) {
if (!message.trim()) return; // empty messages are dropped by the backend anyway
return invoke('update_log', { message, level: ['error','warn','warning'].includes(level) ? level : 'info' });
} Type guard
function isLogLevel(l: unknown): l is 'error' | 'warn' | 'warning' | 'info' {
return typeof l === 'string' && ['error','warn','warning','info'].includes(l);
} Try / catch
try {
await safeUpdateLog(msg, level);
} catch (e) {
console.error('[Updater] failed to relay log to backend', e); // logging must never break the updater
} Prevention
- Never let log relay failures break the updater flow
- Pass explicit level strings matching backend expectations
- Keep messages non-empty and bounded in size
- Use structured payloads instead of free-form strings when possible
When it happens
Trigger: Any frontend code invoking the update_log Tauri command with level 'error' produces this error-tagged line; the underlying updater failure text is whatever the frontend passed in `message`.
Common situations: Frontend updater flow reporting download/install/check failures; empty messages are silently ignored (early return Ok), so nothing is thrown here.
Related errors
- [App] Silent update download failed, retrying (${retryIndex}
- [StartupPerf][UpdaterCommand] update_last_check_time failed
- [StartupPerf][UpdaterCommand] get_update_settings failed in
- [StartupPerf][UpdaterCommand] check_version_jump failed in {
- [AccountGroups] Failed to load groups: ${String(error)}
AI-assisted analysis of jlcodes99/cockpit-tools@1ed8b77992 (2026-09-05).
Data as JSON: /api/errors/8bed8c11e5336ad1.
Report an issue: GitHub.