What causes "model discovery failed (status: ${current.status})" in multica-ai/multica?

Inspect the runtime daemon logs for the underlying failure — this error is a client-side wrapping of a server/daemon-side failure whose detail was not propagated.

multica-ai/multica · error

model discovery failed (status: ${current.status})

Error message

model discovery failed (status: ${current.status})

What it means

Thrown by resolveRuntimeModels when the discovery job reached a terminal status other than 'completed' (typically 'failed') and the server did not supply an error message. The code prefers current.error and only falls back to this template string. Per the source comment, unknown statuses from a newer server or malformed-record fallbacks are deliberately surfaced as errors so the picker shows 'discovery failed' instead of rendering an authoritative-looking empty dropdown.

Source

Thrown at packages/core/runtimes/models.ts:57

): Promise<RuntimeModelsResult> {
  const initial = await api.initiateListModels(runtimeId);
  const start = Date.now();
  let current = initial;
  while (current.status === "pending" || current.status === "running") {
    if (Date.now() - start > POLL_TIMEOUT_MS) {
      throw new Error("model discovery timed out");
    }
    await new Promise((resolve) => setTimeout(resolve, POLL_INTERVAL_MS));
    current = await api.getListModelsResult(runtimeId, initial.id);
  }
  // Only an explicit `completed` is a catalog. Anything else — failed, timeout,
  // or a status this client does not know (newer server, or a response that fell
  // back to the malformed-record shape) — is surfaced as an error so the picker
  // shows "discovery failed" and keeps manual entry available. Treating an
  // unrecognised status as success would render an empty dropdown that looks
  // authoritative.
  if (current.status !== "completed") {
    throw new Error(
      current.error || `model discovery failed (status: ${current.status})`,
    );
  }
  return {
    models: current.models ?? [],
    supported: current.supported !== false,
    cached: current.cached === true,
    cachedAt: current.cached_at,
  };
}

// staleTimeFor is the freshness policy, split out so it can be unit-tested
// without a QueryClient.
//
// A cached answer is treated as stale immediately. The server serves a snapshot
// up to `modelCatalogServeWindow` old and queues its own background refresh;
// if the client ALSO held that response as fresh for minutes, the observable
// staleness would be server window + client window (and the refreshed catalog

View on GitHub (pinned to 2c0912b6ec)

Solutions

Inspect the runtime daemon logs for the underlying failure — this error is a client-side wrapping of a server/daemon-side failure whose detail was not propagated.
Verify the runtime is running and its model listing works outside the app (e.g. run the runtime's own list-models command).
Align client and server versions: an unrecognized status usually means the server is newer than the packages/core client that consumes it.
Restart the runtime daemon and re-run discovery; a transient daemon crash surfaces as a bare 'failed' status.
Keep manual model entry as the user-facing fallback — the picker intentionally leaves manual entry available when this error is shown.

Defensive patterns

Strategy: try-catch

Type guard

function isCompletedDiscovery(r: { status: string }): boolean {
  return r.status === "completed";
}

Try / catch

try {
  const { models, cached } = await resolveRuntimeModels(runtimeId);
} catch (err) {
  // err.message is server's current.error when present, else the status template.
  // Show 'discovery failed' and keep manual entry available — never render an empty dropdown.
  showDiscoveryFailed(err instanceof Error ? err.message : String(err));
}

Prevention

Keep packages/core and the server on compatible versions so status vocabularies match.
Log current.status when this fires — an unrecognized status is a version-skew signal worth reporting.
Always wire the manual model-entry fallback into any UI that consumes discovery.

When it happens

Trigger: Runtime daemon reports status 'failed' with an empty error field; server version newer than the client returns a status value this client does not recognize; the list-models result record fell back to a malformed-record shape; runtime process crashed mid-job and the server marked the job failed without an error string.

Common situations: Version skew between server and packages/core client; runtime binary missing or incompatible; daemon lost connection to the runtime mid-discovery; corrupted job result rows on the server.

Related errors

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