multica-ai/multica · error

repo is configured but not synced: %s

Error message

repo is configured but not synced: %s

What it means

The repo URL is configured for the workspace and the repo list refreshed successfully, but the requested repo is not in the synced set — and the last sync attempt for the workspace recorded an error, which is appended for diagnosis. This is the informative sibling of the bare 879: it tells you WHY the sync didn't produce the repo (e.g. clone failure, auth failure to the git remote).

Source

Thrown at server/internal/daemon/daemon.go:3391

	if !d.workspaceRepoAllowed(workspaceID, repoURL) {
		return ErrRepoNotConfigured
	}

	if d.repoCache.Lookup(workspaceID, repoURL) != "" {
		return nil
	}

	d.syncWorkspaceReposContext(ctx, workspaceID, resp.Repos)
	if err := ctx.Err(); err != nil {
		return context.Cause(ctx)
	}

	if d.repoCache.Lookup(workspaceID, repoURL) != "" {
		return nil
	}

	if syncErr := d.workspaceLastRepoSyncErr(workspaceID); syncErr != "" {
		return fmt.Errorf("repo is configured but not synced: %s", syncErr)
	}

	return fmt.Errorf("repo is configured but not synced")
}

// DefaultTokenRenewalInterval is how often the daemon asks the server to
// extend its PAT. The server-side threshold is 7 days of remaining lifetime;
// polling every ~3 days gives at least two chances to renew before the
// window closes, so a single failed call (network blip, server restart) does
// not push the token out of the renewal window.
const DefaultTokenRenewalInterval = 3 * 24 * time.Hour

// preflightAuth runs the two auth-sensitive startup steps in their
// required order: a synchronous PAT renewal first, then the initial
// workspace sync. The order matters — running tryRenewToken before any
// other API call is what surfaces a user-actionable "run multica login"
// WARN when the PAT is already revoked or expired. If we let the
// workspace sync go first, its 401 would short-circuit Run before the

View on GitHub (pinned to 2c0912b6ec)

Solutions

  1. Read the appended sync error — it names the actual git failure (auth, DNS, timeout)
  2. Fix git credentials for the remote (e.g. refresh the GitHub PAT used by the workspace) and trigger a workspace repo re-sync
  3. Verify the git host is reachable from the daemon host and the workspaces root has free disk
  4. Confirm the repoURL string matches exactly what is configured (trailing .git, scheme, case)
Defensive patterns

Strategy: retry

Validate before calling

// Before dispatch, confirm the repo is present and healthy.
if d.repoCache.Lookup(workspaceID, repoURL) == "" {
    if syncErr := d.workspaceLastRepoSyncErr(workspaceID); syncErr != "" {
        return fmt.Errorf("workspace repo sync previously failed (%s); fix credentials and re-sync before dispatching", syncErr)
    }
}

Try / catch

Parse out the appended sync error; retry the task dispatch after re-triggering the workspace sync. Do NOT retry blindly — an auth failure against the git remote is deterministic until credentials change.

Prevention

When it happens

Trigger: Requesting a task whose repoURL is in the workspace's allow-list while the workspace's background repo sync failed — bad git credentials, unreachable git host, clone timeout, or disk full in the workspaces root.

Common situations: Expired git provider tokens (GitHub PAT), private repo the daemon cannot clone, git host outage, full disk, or a first sync still in flight/failed before the task arrived.

Related errors


AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15). Data as JSON: /api/errors/3000a6ad4782f4f4. Report an issue: GitHub.