clockworklabs/SpacetimeDB · warning · anyhow::Error

Aborted

Error message

Aborted

What it means

`spacetime server fingerprint <server>` fetches the server's current fingerprint (its long-term public key used to pin TLS), compares it with the one saved in CLI config, and prints old vs new when they differ (or prints the new one when none was saved). It then asks 'Continue?' before persisting; this error means you declined, so the config keeps the previous fingerprint. This is the same trust decision as SSH's 'host key changed' warning.

Solutions

  1. If you know the server legitimately changed (reinstall/dev server), re-run and answer 'y', or pass `--force` to accept non-interactively.
  2. If the change is unexpected, stop and verify the new fingerprint out-of-band before trusting it; do not blindly --force.
  3. Alternatively remove and re-add the server: `spacetime server remove <name>` then `spacetime server add ...`.

Example fix

# before
spacetime server fingerprint myserver   # answer n -> Aborted
# after
spacetime server fingerprint myserver --force
Defensive patterns

Strategy: validation

Validate before calling

# Non-interactive provisioning: pin the expected fingerprint out-of-band
EXPECTED=<sha256 of server cert/public key>
ACTUAL=$(spacetime server fingerprint myserver --force 2>/dev/null)
# compare EXPECTED vs the printed fingerprint in your provisioning logic before trusting

Try / catch

Wrap `spacetime server fingerprint` and on 'Aborted' exit, surface the old/new fingerprints from stdout for an out-of-band trust decision instead of failing silently

Prevention

When it happens

Trigger: `spacetime server fingerprint <server>` without --force where the server's keypair changed (reinstall, fresh data dir, new container) or no fingerprint was stored yet, and the user answers 'n' to 'Continue?'.

Common situations: Local `spacetime start` recreated with a wiped data dir/keys; testnet or staging infrastructure rotation; the rare genuine man-in-the-middle case -- the one situation where declining is correct.

Related errors


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

Appendix: 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 6dee26c6ef)