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
- Aggregate the summary by top-level provider only (<=32 distinct providers is the expected domain).
- Fold long-tail providers into an 'other' bucket once the map exceeds ~30 keys.
- If genuinely more than 32 providers, report the top N by count and merge the rest.
- 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
- Key the summary by bare provider name — never provider+version or other composite keys.
- Add the 'other' bucket strategy to the reporter so the cap can never be exceeded organically.
- Monitor cardinality client-side: if providers exceed ~30, that is a key-generation bug until proven otherwise.
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
- runtime probe_result must be success or error
- failed runtime probes must not include counts
- successful runtime probes require all counts
- invalid runtime counts
- invalid runtime provider summary
AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15).
Data as JSON: /api/errors/f7b5f07c12099c4c.
Report an issue: GitHub.