multica-ai/multica · error

repo cache not initialized

Error message

repo cache not initialized

What it means

Returned as HTTP 500 by the daemon's repo checkout endpoint when the handler needs the shared repository cache (d.repoCache) but it was never constructed. The repo cache is the component that clones/fetches git repositories and manages worktrees; without it no checkout can proceed. It indicates the daemon process came up in a configuration where repository caching was disabled or failed to initialize at startup.

Source

Thrown at server/internal/daemon/health.go:252

		if req.URL == "" {
			http.Error(w, "url is required", http.StatusBadRequest)
			return
		}
		if req.WorkspaceID == "" {
			http.Error(w, "workspace_id is required", http.StatusBadRequest)
			return
		}
		if req.WorkDir == "" {
			http.Error(w, "workdir is required", http.StatusBadRequest)
			return
		}
		if req.CheckoutMode != "" && req.CheckoutMode != repoCheckoutModeIsolated {
			http.Error(w, "invalid checkout_mode", http.StatusBadRequest)
			return
		}

		if d.repoCache == nil {
			http.Error(w, "repo cache not initialized", http.StatusInternalServerError)
			return
		}

		if err := d.ensureRepoReady(r.Context(), req.WorkspaceID, req.URL); err != nil {
			if r.Context().Err() != nil {
				d.logger.Debug("repo checkout readiness cancelled", "url", req.URL, "error", err)
				return
			}
			statusCode := http.StatusInternalServerError
			if errors.Is(err, ErrRepoNotConfigured) {
				statusCode = http.StatusBadRequest
			}
			d.logger.Error("repo checkout readiness failed", "workspace_id", req.WorkspaceID, "url", req.URL, "error", err)
			http.Error(w, err.Error(), statusCode)
			return
		}

		checkoutRef := strings.TrimSpace(req.Ref)

View on GitHub (pinned to 2c0912b6ec)

Solutions

  1. Check the daemon startup flags/config for the option that constructs the repo cache and enable it, then restart the daemon.
  2. Inspect daemon startup logs for a failed repo-cache initialization (bad cache dir, permission error on the cache root) and fix the underlying cause.
  3. If running a custom/embedded daemon, verify the code path that assigns d.repoCache runs before the HTTP handlers are registered.
  4. As a quick diagnostic, hit the daemon health/status endpoint to confirm which subsystems report initialized.

Example fix

// before: daemon started with repo cache disabled
daemon.Start(cfg) // cfg.DisableRepoCache = true

// after: enable the repo cache in daemon config
// before
cfg.DisableRepoCache = true
// after
cfg.DisableRepoCache = false
daemon.Start(cfg)
Defensive patterns

Strategy: validation

Validate before calling

// client: probe daemon readiness before checkout
resp, _ := http.Get(daemonBase + "/healthz")
if resp.StatusCode != 200 { log.Fatal("daemon not ready") }

Try / catch

resp, err := client.Do(req)
if err == nil && resp.StatusCode == 500 && strings.Contains(body, "repo cache not initialized") {
    // server-side config problem: report to operator, do not retry blindly
}

Prevention

When it happens

Trigger: POST to the daemon's repo checkout endpoint (the handler validating workdir/checkout_mode in server/internal/daemon/health.go) while the daemon was started without a repo cache — e.g. a flag/config that disables repo caching, a startup initialization error that left d.repoCache nil, or running a daemon build that intentionally omits the cache.

Common situations: Local dev daemon launched with cache disabled; a config regression after upgrading the daemon; a staging daemon whose cache initialization failed silently at boot; tests that spin up the daemon handler struct without wiring a cache.

Related errors


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