What causes "New binary validation failed" in nikivdev/code?

Run the extracted binary manually with `--version` to see the real error (exec format error, missing .so, etc.).

New binary validation failed

Error message

New binary validation failed

What it means

`validate_binary` (src/upgrade.rs:~470) smoke-tests the freshly downloaded binary by running `<path> --version` via `Command::new`. If the process cannot produce a successful exit status, the upgrade aborts with "New binary validation failed" to avoid replacing the working executable with a broken one.

Source

Thrown at src/upgrade.rs:476

    let source_assets = bundle_root.join("share").join("flow");
    if !source_assets.is_dir() {
        return Ok(());
    }
    let Some(dest_assets) = runtime_assets::installed_assets_root_for_exe(output_path) else {
        return Ok(());
    };
    copy_dir_recursive(&source_assets, &dest_assets)
}

/// Validate the new binary by running --version.
fn validate_binary(path: &Path) -> Result<String> {
    let output = Command::new(path)
        .arg("--version")
        .output()
        .context("Failed to validate new binary")?;

    if !output.status.success() {
        bail!("New binary validation failed");
    }

    Ok(String::from_utf8_lossy(&output.stdout).trim().to_string())
}

/// Replace the current executable with the new one.
fn replace_executable(new_exe: &Path, current_exe: &Path) -> Result<()> {
    #[cfg(unix)]
    {
        // On Unix, we can delete the running executable and replace it
        fs::remove_file(current_exe).context("Failed to remove current executable")?;
        fs::copy(new_exe, current_exe).context("Failed to copy new executable")?;

        // Set executable permissions
        use std::os::unix::fs::PermissionsExt;
        let mut perms = fs::metadata(current_exe)?.permissions();
        perms.set_mode(0o755);
        fs::set_permissions(current_exe, perms)?;

View on GitHub (pinned to a747e741ae)

Solutions

Run the extracted binary manually with `--version` to see the real error (exec format error, missing .so, etc.).
Confirm the downloaded asset matches your OS and architecture, then re-run the upgrade.
Check `file <binary>` — 'cannot execute binary file' means wrong arch or truncated download.
Re-download after the maintainers fix the release, or pin/downgrade to the previous working version.
Run `chmod +x <binary>` if the exec bit is missing and retry.

Defensive patterns

Strategy: validation

Validate before calling

# smoke-test before replacing the installed binary
file "$NEW_BIN"                       # right arch? complete file?
chmod +x "$NEW_BIN" && "$NEW_BIN" --version || echo "new binary broken; keep current version"

Prevention

Match the asset to your OS/arch (aarch64 vs x86_64, musl vs glibc).
Keep the previous binary until the new one passes `--version`.
Run the extracted binary manually to see loader errors before upgrading.
On macOS, clear quarantine: `xattr -d com.apple.quarantine <bin>`.

When it happens

Trigger: Running the extracted binary with `--version` returns a non-zero exit code: the artifact is for the wrong OS/architecture, is truncated/corrupt, lacks the exec bit or fails to load its dynamic libraries, or the new version's `--version` flag changed/panics.

Common situations: Downloading an x86_64 build on ARM (Apple Silicon / aarch64 servers); musl vs glibc mismatch causing loader failure; quarantine/Gatekeeper or missing +x permission; broken release CI shipped a bad binary.

Related errors

AI-assisted analysis of nikivdev/code@a747e741ae (2026-09-01). Data as JSON: /api/errors/218da0907e7a63c7. Report an issue: GitHub.