clockworklabs/SpacetimeDB · error

Host {} conflicts with saved configuration for server {}: {}

Error message

Host {} conflicts with saved configuration for server {}: {}://{}

What it means

The host variant of edit_server's conflict guard: changing a server's host to a value that find_server already resolves to another entry. Since hosts are the primary key of the server list (see the add-server check at config.rs:243), two entries may never share a host. The error prints the colliding server's nickname-or-host, protocol and host.

Source

Thrown at crates/cli/src/config.rs:390

        new_protocol: Option<&str>,
    ) -> anyhow::Result<(Option<String>, Option<String>, Option<String>)> {
        // Check if the new nickname or host name would introduce ambiguities between
        // server configurations.
        if let Some(new_nick) = new_nickname
            && let Ok(other_server) = self.find_server(new_nick)
        {
            anyhow::bail!(
                "Nickname {} conflicts with saved configuration for server {}: {}://{}",
                new_nick,
                other_server.nick_or_host(),
                other_server.protocol,
                other_server.host
            );
        }
        if let Some(new_host) = new_host
            && let Ok(other_server) = self.find_server(new_host)
        {
            anyhow::bail!(
                "Host {} conflicts with saved configuration for server {}: {}://{}",
                new_host,
                other_server.nick_or_host(),
                other_server.protocol,
                other_server.host
            );
        }

        let cfg = self.find_server_mut(server)?;
        let old_nickname = if let Some(new_nickname) = new_nickname {
            cfg.nickname.replace(new_nickname.to_string())
        } else {
            None
        };
        let old_host = if let Some(new_host) = new_host {
            Some(std::mem::replace(&mut cfg.host, new_host.to_string()))
        } else {
            None

View on GitHub (pinned to 524b4487d9)

Solutions

  1. Give the edited server a host no other entry uses (`spacetime server list` to check)
  2. If two entries must reach the same host, remove the redundant entry and keep one
  3. Check for a leading-scheme or trailing-slash difference that makes the new host textually identical to an existing one

Example fix

# before (fails: host already configured on entry 'mainnet')
spacetime server edit staging --host testnet.spacetime.io

# after
spacetime server edit staging --host staging.spacetime.io
Defensive patterns

Strategy: validation

Validate before calling

#!/usr/bin/env bash
# Guard an unattended host change
NEW_HOST='staging.spacetime.io'
if spacetime server list | grep -q "$NEW_HOST"; then
  echo "host already configured; skipping edit" >&2
else
  spacetime server edit staging --host "$NEW_HOST"
fi

Try / catch

match config.edit_server(server, None, Some(new_host), None) {
    Ok(res) => res,
    Err(e) if e.to_string().starts_with("Host") && e.to_string().contains("conflicts with saved configuration") => {
        // host already owned by another entry; remove that entry or pick another host
        return Err(e);
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: `spacetime server edit <server> --host <new_host>` (or the equivalent host-change API) where <new_host> matches another configured server's host or nickname.

Common situations: Pointing two named entries (e.g. 'staging' and 'prod') at the same URL; editing a host to add/remove a port and accidentally matching another entry; migrating a server's URL that another entry already uses.

Related errors


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