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

  1. Find and fix the producer generating unbounded distinct scope names; use stable, static ActivitySource/Meter names.
  2. Reduce the number of distinct instrumentation scopes in the emitting applications (share one Meter/ActivitySource per component).
  3. 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

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


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)