What causes "[StartupPerf][UpdaterCommand] check_version_jump failed in {}ms: {}" in jlcodes99/cockpit-tools?

Inspect the inner err to distinguish read vs write failure on the version marker.

[StartupPerf][UpdaterCommand] check_version_jump failed in

Error message

[StartupPerf][UpdaterCommand] check_version_jump failed in {}ms: {}

What it means

The check_version_jump command compares current vs previously-run version to detect a version jump; on Err it logs '[StartupPerf][UpdaterCommand] check_version_jump failed in {ms}ms: {err}' and returns the error. It means the version-jump detection (reading stored last-version and comparing) failed.

Solutions

Inspect the inner err to distinguish read vs write failure on the version marker.
Check permissions on the config/data directory holding the version marker.
Delete a corrupted version marker file so it is recreated on next startup.
Retry after other startup update tasks complete to avoid file contention.

Defensive patterns

Strategy: fallback

Validate before calling

const marker = await readVersionMarker().catch(() => null);
if (marker !== null && !isValidVersion(marker)) await invoke('reset_version_marker');

Type guard

function isSemver(v: unknown): v is string {
  return typeof v === 'string' && /^\d+\.\d+\.\d+/.test(v);
}

Try / catch

try {
  const jump = await invoke('check_version_jump');
} catch (e) {
  // treat as 'no jump' and continue startup
  const jump = null;
  console.warn('version jump check skipped', e);
}

Prevention

Write the version marker atomically after successful startup
Handle first-run (missing marker) as a normal case, not an error
Keep version strings strictly semver-formatted
Sequence version check after settings store is available

When it happens

Trigger: update_checker::check_version_jump returns Err: cannot read the stored last-run version (settings/registry file access), or persisting the new version after a jump fails.

Common situations: First run after install/update with missing or corrupted version marker file; read-only config dir; concurrent startup writers locking the version store.

Related errors

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

Appendix: source

Thrown at src-tauri/src/commands/update.rs:116

}

/// Check if a version jump occurred (for post-update changelog display)
#[tauri::command]
pub fn check_version_jump() -> Result<Option<VersionJumpInfo>, String> {
    let started = Instant::now();
    let result = update_checker::check_version_jump();
    match &result {
        Ok(Some(info)) => logger::log_info(&format!(
            "[StartupPerf][UpdaterCommand] check_version_jump hit in {}ms: {} -> {}",
            started.elapsed().as_millis(),
            info.previous_version,
            info.current_version
        )),
        Ok(None) => logger::log_info(&format!(
            "[StartupPerf][UpdaterCommand] check_version_jump completed in {}ms: no jump",
            started.elapsed().as_millis()
        )),
        Err(err) => logger::log_error(&format!(
            "[StartupPerf][UpdaterCommand] check_version_jump failed in {}ms: {}",
            started.elapsed().as_millis(),
            err
        )),
    }
    result
}

/// Read release history from changelog files
#[tauri::command]
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

View on GitHub (pinned to 1ed8b77992)