The scoped IServiceProvider is passed to AddSingleton in Host V4

[andreasohlund]

Check for a solution in the Azure portal

Nothing found

Investigative information

Please provide the following:

• Timestamp: N/A
• Function App version: N/A
• Function App name: N/A
• Function name(s) (as appropriate): N/A
• Invocation ID: N/A
• Region: N/A

Repro steps

Provide the steps required to reproduce the problem:

1. Register a singleton singing the AddSingleton<T>(Func<IServiceProvider, T> factory) overload.
2. Notice that the IServiceProvider is the scoped one from the first invocation
3. Use of the service provider after the first invocation blows up since the provider has been disposed

Expected behavior

The root IServiceProvider passed to singleton registrations.

Actual behavior

Incorrect IServiceProvider is passed.

Known workarounds

Refactoring the code to use the AddSingletion<T>() overload works and will give the correct IServiceProvider if T has a dependency on IServiceProvider. Here is an example of the workaround we had to use.

Related information

Works as expected in Host V3 so this is a regression bug.

[danielmarbach]

Here is a sample showing how ASP.NET Core exhibits the correct behavior

Program.zip

[NickCraver]

cc @fabiocav this is related to what we were discussing earlier on child containers

[andreasohlund]

Any updates on this?

[liliankasem]

It looks like this is related to making the behaviour behind the “EnableEnhancedScopes” feature flag in v3 the default in v4, which was originally introduced here #6721. We'll continue investigating and are looking to have design discussions on how to address this in the coming sprint.

[fabiocav]

Moving to 119, but the work for this has been in PR and approved.

@brettsam are you still blocked on anything? We should try to get those changes in so the issues are resolved and we can iterate on follow up items.