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).await

View on GitHub (pinned to 1ed8b77992)

Solutions

  1. Look at the text after '[Updater] ' for the real frontend-reported updater failure.
  2. Check frontend updater code that calls invoke('update_log', ...) to see the originating condition.
  3. If logs are missing entirely, verify the frontend passes a non-empty message, since empty messages are dropped.
  4. 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

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


AI-assisted analysis of jlcodes99/cockpit-tools@1ed8b77992 (2026-09-05). Data as JSON: /api/errors/8bed8c11e5336ad1. Report an issue: GitHub.