clockworklabs/SpacetimeDB · warning · anyhow::Error

Aborted

Error message

Aborted

What it means

`spacetime server fingerprint` calls `update_server_fingerprint`, which contacts the server and compares its presented fingerprint against the one stored in config. If the fingerprint changed (the function returns true after storing the new one), the CLI prompts 'Continue?' — the server's identity differs from what you pinned, which can be benign re-deployment or an interception. Declining bails with 'Aborted' before `config.save()`.

Source

Thrown at crates/cli/src/subcommands/server.rs:275

            Ok(true)
        }
    } else {
        println!("No saved fingerprint for server {nick_or_host}. New fingerprint:\n{new_fing}");

        config.set_server_fingerprint(server, new_fing)?;

        Ok(true)
    }
}

pub async fn exec_fingerprint(mut config: Config, args: &ArgMatches) -> Result<(), anyhow::Error> {
    let server = args.get_one::<String>("server").unwrap().as_str();
    let force = args.get_flag("force");

    if update_server_fingerprint(&mut config, Some(server)).await? {
        if !y_or_n(force, "Continue?")? {
            anyhow::bail!("Aborted");
        }

        config.save();
    }

    Ok(())
}

pub async fn exec_ping(config: Config, args: &ArgMatches) -> Result<(), anyhow::Error> {
    let server = args.get_one::<String>("server").unwrap().as_str();
    let url = config.get_host_url(Some(server))?;

    let builder = reqwest::Client::new().get(format!("{url}/v1/ping").as_str());
    let response = builder.send().await?;

    match response.status() {
        reqwest::StatusCode::OK => {
            println!("Server is online: {url}");

View on GitHub (pinned to 524b4487d9)

Solutions

  1. If you expect the change (dev restart, announced rotation), re-run and answer `y`, or pass `--force` to skip the prompt — the new fingerprint is then saved
  2. If the change is unexpected, verify the server out-of-band before trusting it — a changed fingerprint can indicate interception
  3. Pin afresh by removing and re-adding the server with fingerprint verification if the stored state is confusing
  4. For local servers with unstable keys, add with `--no-fingerprint` to avoid TOFU churn

Example fix

# before
spacetime server fingerprint local   # fingerprint changed -> declined -> Aborted
# after
spacetime server fingerprint local --force
Defensive patterns

Strategy: try-catch

Validate before calling

# Non-interactive: decide ahead of time to trust fingerprint changes
spacetime server fingerprint myserver --force   # or omit --force to gate on the prompt

Try / catch

// Guard automation: only auto-accept fingerprint changes for local dev servers
if is_local(server) { run("spacetime server fingerprint", ["--force"]) } else { prompt_human(server) }

Prevention

When it happens

Trigger: The server's TLS/host key legitimately rotated (redeploy, container rebuild, ephemeral dev keys) or was never pinned for this server; the user answers anything other than `y`, or stdin closes, at the Continue? prompt; `--force` was not passed.

Common situations: Local `spacetimedb` node restarted with a regenerated key; testnet/maincloud cert rotation; shared dev server re-provisioned; security-conscious users declining when the change is unexpected.

Related errors


AI-assisted analysis of clockworklabs/SpacetimeDB@524b4487d9 (2026-08-16). Data as JSON: /api/errors/5a49dff322ca5ce3. Report an issue: GitHub.