You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The feature flag EnableEnhancedScopes changes how dependency injection scopes are resolved from within the JobHost. This was added to prevent any major breaking change, but it has fixed a number of dependency scoping problems for users without any known issues.
Without this flag, scopes are passed via an AsyncLocal which can be problematic in some scenarios (most notably when using HttpClient).
We consider the new scope resolution behavior to be the correct behavior, but were trying to mitigate risk by hiding it behind a feature flag. We should use the new behavior going forward.
Impact
This will impact all customers as dependency resolution is used everywhere. It's a bigger impact to .NET in-proc customers, but we believe the behavior with the flag is the correct behavior.
Compat-mode support
We can introduce a DisableEnhancedScopes flag that puts things back the way they were in v3.
Alternatives
There's no real alternatives that don't involve changes to service resolution. There was a long investigation that led to this flag and behavior being added.
Detection
Not really. Before this flag, a number of odd ObjectDisposedExceptions and null-refs would be seen. Only when we got a number of issues around HttpClient usage did we start diving into the issue we were seeing.
Support
This isn't a change that most customers will notice, and we don't believe anyone is depending on the previous behavior.
Documentation
None
Components impacted
This only involves a change to the host.
Performance
No performance impact.
The text was updated successfully, but these errors were encountered:
The feature flag
EnableEnhancedScopes
changes how dependency injection scopes are resolved from within the JobHost. This was added to prevent any major breaking change, but it has fixed a number of dependency scoping problems for users without any known issues.Without this flag, scopes are passed via an AsyncLocal which can be problematic in some scenarios (most notably when using HttpClient).
This was introduced here: Azure/azure-functions-host#6721
Motivation
We consider the new scope resolution behavior to be the correct behavior, but were trying to mitigate risk by hiding it behind a feature flag. We should use the new behavior going forward.
Impact
This will impact all customers as dependency resolution is used everywhere. It's a bigger impact to .NET in-proc customers, but we believe the behavior with the flag is the correct behavior.
Compat-mode support
We can introduce a
DisableEnhancedScopes
flag that puts things back the way they were in v3.Alternatives
There's no real alternatives that don't involve changes to service resolution. There was a long investigation that led to this flag and behavior being added.
Detection
Not really. Before this flag, a number of odd ObjectDisposedExceptions and null-refs would be seen. Only when we got a number of issues around HttpClient usage did we start diving into the issue we were seeing.
Support
This isn't a change that most customers will notice, and we don't believe anyone is depending on the previous behavior.
Documentation
None
Components impacted
This only involves a change to the host.
Performance
No performance impact.
The text was updated successfully, but these errors were encountered: