dotnet/orleans · warning · NotSupportedException

The frontend cant support more than 6 silos

Error message

The frontend cant support more than 6 silos

What it means

This NotSupportedException is thrown by the ActivationRebalancing playground frontend's StatsController when the Orleans cluster returns detailed grain statistics for more than 5 distinct silos. The playground's chart UI (hard-coded line paths/colors for d3.js) was only built to render a fixed number of silo series, so the controller rejects oversized result sets rather than producing a broken visualization. The guard at line 27 caps siloData.Count at 5 (a literal '6 silos' message is slightly off-by-one versus the check).

Source

Thrown at playground/ActivationRebalancing/ActivationRebalancing.Frontend/Controllers/StatsController.cs:29

    [HttpGet("silos")]
    public async Task<IActionResult> GetStats()
    {
        var grainStats = await clusterClient
            .GetGrain<IManagementGrain>(0)
            .GetDetailedGrainStatistics();

        var siloData = grainStats.GroupBy(stat => stat.SiloAddress)
            .Select(g => new SiloData(g.Key.ToString(), g.Count()))
            .ToList();

        if (siloData.Count == 4)
        {
            siloData = [.. siloData, new SiloData("x", 0)];
        }

        if (siloData.Count > 5)
        {
            throw new NotSupportedException("The frontend cant support more than 6 silos");
        }

        return Ok(siloData);
    }
}

public record SiloData(string Host, int Activations);

View on GitHub (pinned to fca799fa70)

Solutions

1. Reduce the cluster to 5 or fewer silos (the sample's intended size) and re-request /api/stats/silos.
2. If you intentionally need more silos, extend the frontend: increase the d3 linePaths/activationsHistory arrays in index.html and raise the > 5 cap in StatsController to match.
3. Generalize the chart to build its series dynamically from the returned data instead of hardcoding the count, removing the NotSupportedException entirely.

Example fix

// before
if (siloData.Count > 5)
{
    throw new NotSupportedException("The frontend cant support more than 6 silos");
}
return Ok(siloData);

// after (build chart series dynamically client-side)
return Ok(siloData);

// Caller / test harness: check silo count before relying on the endpoint
var stats = await clusterClient.GetGrain<IManagementGrain>(0).GetDetailedGrainStatistics();
var siloCount = stats.Select(s => s.SiloAddress).Distinct().Count();
if (siloCount > 5) { /* scale down or extend frontend before calling /api/stats/silos */ }

// Frontend JS — degrade gracefully instead of breaking the chart on a 500
fetch('/api/stats/silos')
  .then(r => r.ok ? r.json() : Promise.reject(new Error(`status ${r.status}`)))
  .then(updateChart)
  .catch(err => { console.warn('Stats unavailable, keeping last chart', err); });

When it happens

Trigger: A GET /api/stats/silos request resolves, IManagementGrain.GetDetailedGrainStatistics() returns grain stats whose GroupBy(SiloAddress) yields more than 5 distinct silo addresses. This happens when the playground AppHost has been scaled up beyond the 4-5 silos the sample was designed to demo.

Common situations: Running the ActivationRebalancing playground with a larger cluster (e.g., manually adding more silo replicas or running against a shared dev cluster). Modifying the AppHost replica count without updating the frontend's hardcoded chart series.

Related errors

• count
• message
• ReceiptHandle
• queueId
• Message contains no events

AI-assisted analysis of dotnet/orleans@fca799fa70 (2026-08-13). Data as JSON: /api/errors/52baa09f8dda51a4. Report an issue: GitHub.