dotnet/orleans

Breaking change in v8.1.0 when configuring streaming on silo?

christiansparre opened this issue · 2 comments

Hi, I just updated to version 8.1.0 and are suddenly getting the following exception during silo startup

Could not find Streaming provider named 'Default'. This can indicate that either the 'Microsoft.Orleans.Sdk' or the provider's package are not referenced by your application.

I think it relates to the new configuration changes that made Aspire support possible and looks quite a lot like this one #8932 I saw earlier on the "client" side - not exactly the same I guess.

Apparently on https://github.com/dotnet/orleans/blob/v8.1.0/src/Orleans.Runtime/Hosting/DefaultSiloServices.cs#L439 it looks for the provider type in the configuration section and if that does not exist it falls back to "Default" as the provider type

var providerType = configurationSection["ProviderType"] ?? "Default";

However we configure streaming using

builder.SiloBuilder.AddEventHubStreams("default", configurator =>........

With lowercase "default" and get the above exception. I looked through the release notes but have not been able to find any migration guide or mention of this change.

Is there some workaround we can use? I'm not sure it's feasible right now to move all our configuration/startup code to the new IConfiguration based setup.

By doing a separate repro I was able to figure out what is going on. It's here https://github.com/christiansparre/Orleans_Streaming_Config_Repro_20240708/tree/main - more specifically the silo host appsettings.json file is of interest.

We have been using a configuration that looks like this to hold port, reminder and event hub connection information etc. for almost 3 years now:

"Orleans": {
  ...
  "Streaming": {
    "EventHubConnectionString": "...",
    "EventHubName": "..."
  },
  ...
},

The Orleans:Streaming section gets picked up by DefaultSiloServices.ApplyConfiguration and do some default and fallback stuff to configure a "default" streaming provider...

So not really a breaking change apart from for us because we have been using the same configuration naming that Orleans now suddenly started using in a "point" release :)

We will have to figure out how to proceed and how to adopt the change as frankly it ties into our whole environment provisioning process and is currently blocking us from upgrading Orleans to 8.1 and beyond...

Ah yes, I ran into something similar. As a quick fix, I just renamed our Orleans config section to OrleansCustom, and noted that we should probably improve that :)