EE::Namespace#feature_available? return false when the feature is enabled for a specific group or project
The insights
feature was behind a feature flag for the last 2 releases and we enabled it for specific groups and projects meaning that ::Feature.enabled?(feature, <group or project>)
would return true
. This is used in EE::Namespace#beta_feature_available?
.
The problem is that now that we made the feature Generally Available, we've replaced our usage of EE::Namespace#beta_feature_available?
with EE::Namespace#feature_available?
, and this method has a different implementation:
- It
return false unless ::Feature.enabled?(feature, default_enabled: true)
- But since we've enabled the feature for groups/projects and not globally on GitLab.com right now, this condition actually evaluates to
false
, meaning thatEE::Namespace#feature_available?
returnsfalse
for the groups/projects that we specifically enabled theinsights
feature flag for.
The easy fix for GitLab.com is to remove the feature flag value entirely (using the ChatOps or API) once it's deployed to production.
A proper long-term fix would be to make EE::Namespace#feature_available?
check for ::Feature.enabled?(feature, self, default_enabled: true)
in addition to ::Feature.enabled?(feature, default_enabled: true)
, i.e.
def feature_available?(feature)
# This feature might not be behind a feature flag at all, so default to true
return false unless ::Feature.enabled?(feature, default_enabled: true) || ::Feature.enabled?(feature, self, default_enabled: true)
available_features = strong_memoize(:feature_available) do
Hash.new do |h, f|
h[f] = load_feature_available(f)
end
end
available_features[feature]
end