microsoft/aspire · error · InvalidOperationException
Scope limit of reached for . Scope ' ' will not be added.
Error message
Scope limit of {TelemetryRepositoryLimits.MaxScopeCount} reached for {telemetryType}. Scope '{name}' will not be added. What it means
Aspire Dashboard caps the number of distinct instrumentation scopes (OtlpScope) it keeps in memory per telemetry type via TelemetryRepositoryLimits.MaxScopeCount. TryGetOrAddScope throws this InvalidOperationException when a new scope arrives and the cache is already at the limit; the scope (and its telemetry) is not added. The limit protects the Dashboard from unbounded memory growth caused by hosts that generate endless unique scope identities.
Solutions
- Find and fix the producer generating unbounded distinct scope names; use stable, static ActivitySource/Meter names.
- Reduce the number of distinct instrumentation scopes in the emitting applications (share one Meter/ActivitySource per component).
- Filter or aggregate telemetry upstream in an OpenTelemetry Collector so fewer scopes reach the Dashboard.
Example fix
// before: unique scope per instance
var source = new ActivitySource($"MyApp.{Guid.NewGuid()}");
// after: stable scope name
var source = new ActivitySource("MyApp"); Defensive patterns
Strategy: try-catch
Try / catch
try
{
repository.AddTraces(request);
}
catch (InvalidOperationException ex) when (ex.Message.Contains("Scope limit of"))
{
logger.LogWarning(ex, "Scope limit reached; scope '{Scope}' dropped.", scopeName);
} Prevention
- Use static, stable ActivitySource/Meter names; never embed ids or timestamps in scope names.
- Audit libraries for dynamically-generated instrumentation scope names.
- Keep the count of distinct instrumentation scopes small per application.
When it happens
Trigger: TryGetOrAddScope throws when scopes.Count >= TelemetryRepositoryLimits.MaxScopeCount and an unseen scope name/version/attributes tuple is added while importing logs, metrics, or traces. Happens on the OTLP ingestion path when telemetry carries more distinct InstrumentationScope values than the configured maximum.
Common situations: Applications with dynamically-named ActivitySource/Meter names (e.g. names embedding ids or timestamps); many microservices each with unique scopes funneling into one Dashboard; a bug causing a new scope identity per request; environment where the incoming telemetry volume is much higher than the Dashboard default limit anticipates.
Related errors
- Resource view limit of
- Scope limit of reached. Scope ' ' will not be added.
- Resource limit of reached. Resource ' ' will not be added.
- Resource view limit of
- AppHost:ResourceService:ApiKey is not specified in…
AI-assisted analysis of microsoft/aspire@25830f84bd (2026-09-16).
Data as JSON: /api/errors/950ef01144ab6f64.
Report an issue: GitHub.
Appendix: source
Thrown at src/Aspire.Dashboard/Otlp/Model/OtlpHelpers.cs:528
}
}
public static bool TryGetOrAddScope(Dictionary<string, OtlpScope> scopes, InstrumentationScope? scope, OtlpContext context, TelemetryType telemetryType, [NotNullWhen(true)] out OtlpScope? s)
{
try
{
// The instrumentation scope information for the spans in this message.
// Semantically when InstrumentationScope isn't set, it is equivalent with
// an empty instrumentation scope name (unknown).
var name = scope?.Name ?? string.Empty;
if (scopes.TryGetValue(name, out s))
{
return true;
}
if (scopes.Count >= TelemetryRepositoryLimits.MaxScopeCount)
{
throw new InvalidOperationException($"Scope limit of {TelemetryRepositoryLimits.MaxScopeCount} reached for {telemetryType}. Scope '{name}' will not be added.");
}
s = (scope != null)
? new OtlpScope(scope.Name, scope.Version, scope.Attributes.ToKeyValuePairs(context))
: OtlpScope.Empty;
scopes.Add(name, s);
context.Logger.LogTrace("Added scope '{ScopeName}' to {TelemetryType}.", s.Name, telemetryType);
return true;
}
catch (Exception ex)
{
context.Logger.LogInformation(ex, "Error adding scope to {TelemetryType}.", telemetryType);
s = null;
return false;
}
}View on GitHub (pinned to 25830f84bd)