gastownhall/beads · error
add remote %s: %w
Error message
add remote %s: %w
What it means
ensureDoltRemote adds the remote when no existing remote with that name is found (in the listing or persisted on disk). If st.AddRemote fails, the error is wrapped as 'add remote <name>'. It fails fast before any URL-comparison or replacement logic runs.
Source
Thrown at cmd/bd/dolt.go:1565
if err != nil {
return doltRemoteAddResult{}, fmt.Errorf("list existing remotes: %w", err)
}
existingURL := findDoltRemoteURL(remotes, name)
existingFromDiskOnly := false
if existingURL == "" {
// An empty listing is not proof the remote is absent: a freshly
// (auto-)started sql-server can report empty dolt_remotes while the
// remote is persisted on disk (GH#2118, wy-6k7f7). Recover the
// persisted URL so the add gets the same match/confirm treatment it
// would after the window, instead of silently writing over an
// invisible remote.
existingURL = findDoltRemoteURL(persistedRemoteInfosFor(st), name)
existingFromDiskOnly = existingURL != ""
}
if existingURL == "" {
if err := st.AddRemote(ctx, name, url); err != nil {
return doltRemoteAddResult{}, fmt.Errorf("add remote %s: %w", name, err)
}
return doltRemoteAddResult{}, nil
}
if doltutil.RemoteURLsMatch(existingURL, url) {
return doltRemoteAddResult{}, nil
}
if !confirm("SQL server", name, existingURL, url) {
return doltRemoteAddResult{Canceled: true}, nil
}
if err := st.RemoveRemote(ctx, name); err != nil {
// A remote known only from disk may not be removable through a
// cold-started server that doesn't see it yet; the confirmed add
// below is what establishes the new URL either way.
if !existingFromDiskOnly {
return doltRemoteAddResult{}, fmt.Errorf("remove existing remote %s: %w", name, err)
}View on GitHub (pinned to 71377f2769)
Solutions
- Check the remote URL format (valid git/https/file URL for Dolt remotes) and retry
- Verify server health and retry — AddRemote may have failed transiently
- Run `bd dolt remote -v` to see the current state, then re-add or remove conflicting entries
- Avoid concurrent bd mutations on the same workspace from multiple processes
Example fix
// before bd dolt remote add origin not-a-url // after bd dolt remote add origin https://github.com/org/repo.git
Defensive patterns
Strategy: validation
Validate before calling
u, err := url.Parse(remoteURL)
if err != nil || (u.Scheme != "https" && u.Scheme != "http" && u.Scheme != "file" && u.Scheme != "ssh") {
return fmt.Errorf("invalid remote URL: %q", remoteURL)
} Try / catch
res, err := ensureDoltRemote(ctx, st, name, url, confirm)
if err != nil {
if strings.Contains(err.Error(), "add remote "+name) {
// check URL validity and server state before retrying
return res, err
}
} Prevention
- Validate remote URLs before passing them to bd dolt remote add
- Don't run concurrent remote mutations from multiple shells/CI jobs
- Check `bd dolt remote -v` first to know whether add will be a create or replace
- Use consistent URL normalization (trailing slashes, scheme) across environments
When it happens
Trigger: `bd dolt remote add <name> <url>` (or push-time adoption) when AddRemote errors: invalid URL rejected by the driver, server write failure, or a remote materialized on disk between the listing and the add (race).
Common situations: Malformed remote URL (bad scheme/path); Dolt server hiccup; concurrent bd processes both trying to add the same remote name.
Related errors
- list existing remotes: %w
- remove existing remote %s: %w
- no Dolt remote is configured, and bd will not adopt one with
- remote adoption declined; nothing was written and nothing wa
- inspecting remote target %s: %w
AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30).
Data as JSON: /api/errors/7ebf6bbbb460605e.
Report an issue: GitHub.