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

  1. Check the remote URL format (valid git/https/file URL for Dolt remotes) and retry
  2. Verify server health and retry — AddRemote may have failed transiently
  3. Run `bd dolt remote -v` to see the current state, then re-add or remove conflicting entries
  4. 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

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


AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30). Data as JSON: /api/errors/7ebf6bbbb460605e. Report an issue: GitHub.