multica-ai/multica · warning

too many runtime providers

Error message

too many runtime providers

What it means

validateClientUsageRuntime rejects a success probe whose provider_summary map contains more than 32 entries. The summary is stored as a JSON blob, and the entry cap keeps the per-report payload and stored row size bounded. It is a pure cardinality limit on map keys, independent of the counts' correctness (which is checked separately).

Source

Thrown at server/internal/handler/client_usage.go:206

	if result != "success" && result != "error" {
		return validatedRuntimeProbe{}, errors.New("runtime probe_result must be success or error")
	}
	validated := validatedRuntimeProbe{Result: pgtype.Text{String: result, Valid: true}}
	if result == "error" {
		if probe.RuntimeCount != nil || probe.ProviderSummary != nil || probe.OnlineCount != nil || probe.OfflineCount != nil {
			return validatedRuntimeProbe{}, errors.New("failed runtime probes must not include counts")
		}
		return validated, nil
	}

	if probe.RuntimeCount == nil || probe.ProviderSummary == nil || probe.OnlineCount == nil || probe.OfflineCount == nil {
		return validatedRuntimeProbe{}, errors.New("successful runtime probes require all counts")
	}
	if *probe.RuntimeCount < 0 || *probe.RuntimeCount > 1000 || *probe.OnlineCount < 0 || *probe.OfflineCount < 0 || *probe.OnlineCount+*probe.OfflineCount != *probe.RuntimeCount {
		return validatedRuntimeProbe{}, errors.New("invalid runtime counts")
	}
	if len(probe.ProviderSummary) > 32 {
		return validatedRuntimeProbe{}, errors.New("too many runtime providers")
	}
	var providerTotal int64
	for provider, count := range probe.ProviderSummary {
		if !providerNamePattern.MatchString(provider) || count < 0 || count > 1000 {
			return validatedRuntimeProbe{}, errors.New("invalid runtime provider summary")
		}
		providerTotal += int64(count)
	}
	if providerTotal != int64(*probe.RuntimeCount) {
		return validatedRuntimeProbe{}, errors.New("runtime provider counts do not match runtime_count")
	}
	summary, err := json.Marshal(probe.ProviderSummary)
	if err != nil {
		return validatedRuntimeProbe{}, errors.New("invalid runtime provider summary")
	}
	validated.RuntimeCount = pgtype.Int4{Int32: *probe.RuntimeCount, Valid: true}
	validated.ProviderSummary = summary
	validated.OnlineCount = pgtype.Int4{Int32: *probe.OnlineCount, Valid: true}

View on GitHub (pinned to 2c0912b6ec)

Solutions

  1. Aggregate the summary by top-level provider only (<=32 distinct providers is the expected domain).
  2. Fold long-tail providers into an 'other' bucket once the map exceeds ~30 keys.
  3. If genuinely more than 32 providers, report the top N by count and merge the rest.
  4. Add a client-side guard: if Object.keys(summary).length > 32, merge smallest buckets before sending.

Example fix

// before
const summary = {};
for (const rt of runtimes) summary[`${rt.provider}/${rt.version}`] = (summary[`${rt.provider}/${rt.version}`] || 0) + 1;

// after
const summary = {};
for (const rt of runtimes) summary[rt.provider] = (summary[rt.provider] || 0) + 1;
if (Object.keys(summary).length > 32) mergeSmallestIntoOther(summary);
Defensive patterns

Strategy: validation

Validate before calling

function capProviders(summary, max = 32) {
  const keys = Object.keys(summary);
  if (keys.length <= max) return summary;
  // fold smallest buckets into 'other' to stay within the cap
  const sorted = keys.sort((a, b) => summary[a] - summary[b]);
  const out = {};
  let other = 0;
  sorted.forEach((k, i) => {
    if (i < max - 1) out[k] = summary[k]; else other += summary[k];
  });
  if (other) out.other = other;
  return out;
}

Type guard

const providerCountWithinCap = (summary) => Object.keys(summary).length <= 32;

Prevention

When it happens

Trigger: POST a success probe with a provider_summary containing 33+ distinct provider keys, e.g. synthesized per-provider or per-version keys like 'openai/gpt-4', 'openai/gpt-4o', ... crossing 32 entries.

Common situations: Client keying the summary by provider+model+version instead of provider alone, exploding cardinality; a bug generating dynamic provider names (e.g. embedding an id or timestamp in the key); test fixtures enumerating many fake providers.

Related errors


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