libnyanpasu/clash-nyanpasu · error

{operation} failed with status {status}

Error message

{operation} failed with status {status}

What it means

ensure_success maps a child process's non-zero exit status into an anyhow error, naming the operation performed (e.g. 'macOS DNS cache flush'). It fires when the spawned OS command (ipconfig /flushdns on Windows, dscacheutil/killall on macOS) exits non-zero. It only reports the raw ExitStatus — the command's stderr is not included, which can make diagnosis harder.

Source

Thrown at backend/tauri/src/client/system_dns.rs:61

    let status = std::process::Command::new("/usr/bin/osascript")
        .args(["-e", MACOS_SCRIPT])
        .status()
        .context("failed to request permission to flush the macOS DNS cache")?;

    ensure_success(status, "macOS DNS cache flush")
}

#[cfg(not(any(target_os = "windows", target_os = "macos")))]
fn flush_system_dns_cache() -> anyhow::Result<()> {
    anyhow::bail!("flushing the system DNS cache is not supported on this platform")
}

#[cfg(any(target_os = "windows", target_os = "macos"))]
fn ensure_success(status: std::process::ExitStatus, operation: &str) -> anyhow::Result<()> {
    if status.success() {
        Ok(())
    } else {
        anyhow::bail!("{operation} failed with status {status}")
    }
}

#[cfg(test)]
#[derive(Debug, Default)]
pub struct NoopSystemDnsCache;

#[cfg(test)]
impl SystemDnsCache for NoopSystemDnsCache {
    fn flush(&self) -> anyhow::Result<()> {
        Ok(())
    }
}

#[cfg(all(test, target_os = "windows"))]
mod windows_tests {
    use super::{WINDOWS_ARGS, WINDOWS_PROGRAM};

View on GitHub (pinned to f7dbce2997)

Solutions

1. Re-run the operation from an elevated/privileged context (the flush commands typically need none, but sandboxed/service contexts may block process spawning)
2. Capture and include the child process stderr in the error message to identify the real cause
3. Check the platform command exists (which/where) and handle a missing binary distinctly from a failed run
4. Treat as best-effort: log and continue, since a stale DNS cache rarely blocks operation

Example fix

// before
anyhow::bail!("{operation} failed with status {status}")
// after
anyhow::bail!("{operation} failed with status {status}: {stderr}")

// ensure the platform command exists before spawning
// e.g. `where ipconfig` on Windows, `which dscacheutil` on macOS

if let Err(e) = flush_system_dns_cache() {
    log::warn!("DNS cache flush failed (non-fatal): {e}");
}

When it happens

Trigger: flush_system_dns_cache spawns the platform flush command and it exits with a non-zero status; e.g. ipconfig /flushdns fails due to restricted permissions, or the macOS command is missing/blocked.

Common situations: Running without sufficient privileges in service contexts; hardened/minimal OS images missing dscacheutil or ipconfig; antivirus or sandbox blocking command execution.

Related errors

• child process failed: {:?}, err: {}
• flushing the system DNS cache is not supported on this platf
• {stderr}
• failed to copy core: {status}
• {error}

AI-assisted analysis of libnyanpasu/clash-nyanpasu@f7dbce2997 (2026-09-08). Data as JSON: /api/errors/537b294d8714347f. Report an issue: GitHub.