clockworklabs/SpacetimeDB · error

Nickname {} conflicts with saved configuration for server {}

Error message

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

What it means

edit_server (used by `spacetime server edit`) refuses to rename a server to a nickname that find_server can already resolve — i.e. a string matching another entry's nickname OR host. The uniqueness invariant is what lets every server be addressed unambiguously by name; the error names the colliding server along with its protocol and host so you can see what you collided with.

Source

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

    ///
    /// Implements `spacetime server edit`.
    ///
    /// Returns `Err` if no such server exists.
    /// On success, returns `(old_nickname, old_host, hold_protocol)`,
    /// with `Some` for each field that was changed.
    pub fn edit_server(
        &mut self,
        server: &str,
        new_nickname: Option<&str>,
        new_host: Option<&str>,
        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
            );
        }

View on GitHub (pinned to 524b4487d9)

Solutions

1. Choose a nickname that no other server uses as nickname or host (`spacetime server list` shows current entries)
2. If the old label is the one you want, rename or remove the colliding server first, then retry
3. Address servers by their existing nick_or_host instead of renaming

Example fix

# before (fails: 'mainnet' already identifies another entry)
spacetime server edit testnet-edge --nickname mainnet

# after
spacetime server edit testnet-edge --nickname mainnet-eu

# Derive a nickname guaranteed not to collide before renaming
NEW_NICK="prod-eu"
if ! spacetime server list | grep -q "^${NEW_NICK}\b\| ${NEW_NICK}\b"; then
  spacetime server edit prod --nickname "$NEW_NICK"
fi

match config.edit_server(server, Some(new_nick), None, None) {
    Ok(res) => res,
    Err(e) if e.to_string().starts_with("Nickname") && e.to_string().contains("conflicts with saved configuration") => {
        // pick another name or rename the colliding entry first
        return Err(e);
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: `spacetime server edit <server> --nickname <new_nick>` where <new_nick> equals any other configured server's nickname or host (find_server(new_nick) succeeds on a different entry).

Common situations: Renaming a second entry to a conventional label like 'mainnet', 'testnet' or 'local' when one already uses it; copy-pasting server blocks between machines; renaming during a migration to find the old name taken.

Related errors

• Host {} conflicts with saved configuration for server {}: {}
• Server host name is ambiguous with existing server nickname:
• Server already configured for host: {host}
• Invalid subcommand: {unknown}
• Invalid url: {url}

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