-
Notifications
You must be signed in to change notification settings - Fork 120
Adjusts the configuration provider to no longer check top level for feature flags #261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
cb43b80
to
74ee097
Compare
src/Microsoft.FeatureManagement/ConfigurationFeatureDefinitionProvider.cs
Show resolved
Hide resolved
src/Microsoft.FeatureManagement/ConfigurationFeatureDefinitionProvider.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.FeatureManagement/ConfigurationFeatureDefinitionProvider.cs
Outdated
Show resolved
Hide resolved
d48629c
to
65e8330
Compare
Now pointing this PR at main for a new major version. |
The PR seems messed up. There is a huge change set. |
65e8330
to
b91bc3e
Compare
b91bc3e
to
85b401e
Compare
My fault. Didn't push up the rebase. Should be good now. |
} | ||
else | ||
{ | ||
return _configuration.GetChildren(); | ||
_logger.LogWarning($"No configuration section named '{FeatureManagementSectionName}' was found."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's just no features defined. That's fine. We have a separate flag to throw or not if a requested feature is not found, so that's where any error indication would be applicable I would say.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For developers, this code gets hit on each IsEnabledAsync
call and on direct calls to GetFeatureDefinitionAsync
.
For IsEnabledAsync
, we do log that the feature wasn't found. I'd be okay to take it out, but I think there is some value in indicating that it never found a FeatureManagement section at all.
But for direct calls to GetFeatureDefinitionAsync
, this is the only warning. I suppose the resulting object being empty is indication that something is wrong.
What if we kept it but adjusted it to LogInformation
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LogDebug or LogTrace perhaps. This isn't really valuable information for the application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adjusted to LogDebug
src/Microsoft.FeatureManagement/ConfigurationFeatureDefinitionProvider.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.FeatureManagement/ConfigurationFeatureDefinitionProvider.cs
Show resolved
Hide resolved
src/Microsoft.FeatureManagement/ConfigurationFeatureDefinitionProvider.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.FeatureManagement/ConfigurationFeatureDefinitionProvider.cs
Outdated
Show resolved
Hide resolved
* Adjusts the configuration provider to no longer check top level for feature flags (#261) * Adjusts the configuration provider to no longer check top level for feature flags * Adding missing using and removes unused else * Remove unused string * Add null check to constructor * Updates dependencies. Removes ASP.NET support for netstandard2.0 & tests for netcoreapp2.1 (#267) * Updating dependencies * Updates packages and resolves issues * Remove pointless semicolon * Adjusts dotnet installation for buiddy build * Removes ASP.NET tests from .NET tests * Removes unused usings * Adjust the template type for RazorPages project * Resolves missing ExternalInit for netstandard2.1
With the release of v3 on the horizon, we can start adding misc. features that were waiting for a major version bump.
This adjustment was requested in a couple issues
#144
#254