Guidance for calling GetSiteSettingsAsync() in non-async methods

[rjpowers10]

I have a few cases where I want to read the site settings in a non-async method.

1. IServiceCollection.AddHttpClient Doco
2. IConfigureOptions.Configure Doco

In both cases I have to call GetSiteSettingsAsync().GetAwaiter().GetResult(), which feels dangerous to me.

I noticed in #9270 that @jtkech mentioned the idea of adding a GetSiteSettings() method so it could be called instead of GetSiteSettingsAsync().GetAwaiter().GetResult() and it sounds like that idea was specifically for IConfigureOptions.Configure(). It looks like that was never implemented but I think it's exactly I what I am looking for.

I should be clear that I am currently calling GetSiteSettingsAsync().GetAwaiter().GetResult() and it is not causing any problems for me. My only concern is that I know GetAwaiter().GetResult() is something that should be avoided, so I hope there isn't some future deadlock issue out there waiting to happen.

Thanks!

[hishamco]

I know GetAwaiter().GetResult() is something that should be avoided

I notice that from @Piedone in on of my recent PRs, but again I see the same things in Localization module, when we load the cultures inside Startup

[jtkech]

Yes, always better to get settings asynchronously (e.g. lazily on demand), but if you want to also use the config option pattern (as we do in some places) you have no choice.

We have an action filter that gets site settings, so most of the time we retrieve them from the cache, so no database async I/O and then no problem to get them synchronously. But yes if we use a distributed cache we may still have async I/O, but here much less prone to a dead lock, and about the DI deadlock we did a fix on our side and there is a good chance that it was also fixed in 6.0.