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 {
NoneView on GitHub (pinned to 524b4487d9)
Solutions
- Give the edited server a host no other entry uses (`spacetime server list` to check)
- If two entries must reach the same host, remove the redundant entry and keep one
- 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
- Treat hosts as unique primary keys across all entries; never point two nicknames at the same host
- When a server moves, edit its host in place rather than adding a second entry for the new URL
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
- Server already configured for host: {host}
- Nickname {} conflicts with saved configuration for server {}
- Server nickname {} already in use: {}://{}
- Server host name is ambiguous with existing server nickname:
- Invalid subcommand: {unknown}
AI-assisted analysis of clockworklabs/SpacetimeDB@524b4487d9 (2026-08-16).
Data as JSON: /api/errors/3d3ffef41b86f035.
Report an issue: GitHub.