jlcodes99/cockpit-tools · warning

[SystemConfig] 配置保存失败后回滚应用自启动状态失败: {}

Error message

[SystemConfig] 配置保存失败后回滚应用自启动状态失败: {}

What it means

In patch_general_config (src-tauri/src/commands/system_network_general.rs), if saving the general config fails after the OS auto-launch toggle was already applied, the code attempts to roll back auto-launch to its previous state; if that rollback itself fails it logs this message. The original config-save error is still the primary error; this is a secondary, logged-only failure.

Source

Thrown at src-tauri/src/commands/system_network_general.rs:576

            hide_dock_icon_changed = previous_hide_dock_icon != current.hide_dock_icon;
            tray_icon_style_changed = previous_tray_icon_style != current.tray_icon_style;
            menu_bar_quota_changed = previous_menu_bar_quota
                != (
                    current.menu_bar_quota_enabled,
                    current.menu_bar_show_account_prefix,
                    current.menu_bar_quota_platform.clone(),
                );
        }
        Ok(())
    });

    let new_config = match patch_result {
        Ok(config) => config,
        Err(error) => {
            if auto_launch_os_changed {
                if let Some(previous) = previous_auto_launch {
                    if let Err(rollback_error) = apply_app_auto_launch_enabled(&app, previous) {
                        modules::logger::log_error(&format!(
                            "[SystemConfig] 配置保存失败后回滚应用自启动状态失败: {}",
                            rollback_error
                        ));
                    }
                }
            }
            return Err(error);
        }
    };

    if token_keeper_enabled_changed {
        modules::provider_token_keeper::notify_config_changed(
            app.clone(),
            new_config.token_keeper_enabled,
        );
    }

    if auto_import_from_local_enabled_changed {

View on GitHub (pinned to 1ed8b77992)

Solutions

  1. Fix the primary config-save error first (check the original `error` from patch_result) — often the same permission problem causes both.
  2. Verify the app has permission to modify OS auto-launch entries (Login Items on macOS, registry/Startup folder on Windows, autostart .desktop on Linux).
  3. Manually toggle the app's launch-at-login setting in OS settings to resynchronize state.
  4. Retry the config save after resolving permissions; the rollback message is informational and logged, not returned to the caller.
Defensive patterns

Strategy: try-catch

Validate before calling

// Verify autostart is controllable before toggling it in the same patch
const canToggle = await invoke('can_apply_auto_launch').catch(() => false);
if (!canToggle) throw new Error('当前环境无法修改开机自启动');

Try / catch

const result = await invoke('patch_general_config', { patch });
// rollback failures are logged, not returned; check app logs for the rollback tag:
const logs = await readAppLogs();
if (logs.some(l => l.includes('回滚应用自启动状态失败'))) {
  await invoke('resync_auto_launch_state');
}

Prevention

When it happens

Trigger: patch_user_config/patch_result returned Err while auto_launch_os_changed was true, AND apply_app_auto_launch_enabled(&app, previous) also returned Err during rollback (e.g. autostart backend API failure).

Common situations: The autostart plugin cannot modify the platform's launch registry/agent (permissions, AppArmor/Sandbox restrictions); the app handle's autostart state is out of sync; the config failure was itself caused by the same underlying permission problem.

Related errors


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