-
Notifications
You must be signed in to change notification settings - Fork 55
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
fix: variant fallback usage #171
Conversation
if !f.Enabled { | ||
return defaultVariant |
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.
I don't know when we ever hit this? I couldn't find a way to trigger it. One of the tests uses a default strategy (which is always enabled), but with f.Enabled
set to false. This seems to still hit the previous strategyResult.enabled
, though, so I suspect this isn't used anymore, but I'll leave it in combined with missing flags regardless.
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.
If you were afraid of non idiomatic go, I might not be the best reviewer, but this certainly looks good to me. I understand what you're doing and I like the added tests.
👍
@@ -214,16 +214,20 @@ type variantOption struct { | |||
// VariantOption provides options for querying if a variant is found or not. | |||
type VariantOption func(*variantOption) | |||
|
|||
// WithVariantFallback specifies what the value should be if the variant is not found on the | |||
// unleash service. | |||
// WithVariantFallback specifies what the value should be if the |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
client_test.go
Outdated
|
||
fallbackVariant := api.Variant{ | ||
Name: "fallback-variant", | ||
FeatureEnabled: true, |
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.
Spacing is a bit weird here
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.
That's probably a tabs/spaces thing. Weird that my editor changed to using whatever the other is. Anyway, that line is gone now, so that's not an issue anymore.
|
||
variantWithFallbackFunc := client.GetVariant(feature, WithVariantFallbackFunc(fallbackFunc)) | ||
|
||
assert.Equal(fallbackVariant, *variantWithFallbackFunc) |
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.
While I get that the FeatureEnabled
field is being changed in the previous call to GetVariant
that is a bit confusing here looking at the test. I think it might be better if you did:
fallbackVariant = api.Variant{
Name: "fallback-variant",
FeatureEnabled: true,
}
fallbackFunc := func(feature string, ctx *context.Context) *api.Variant {
return &fallbackVariant
}
then later did the same
assert.False(variantWithFallbackFunc.Enabled)
assert.False(variantWithFallbackFunc.FeatureEnabled)
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.
Removed changing the feature enabled in 251d167 as per your suggestion. With that change, is there still anything here you'd like to address?
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.
Nope, lgtm
|
||
variantWithFallbackFunc := client.GetVariant(feature, WithVariantFallbackFunc(fallbackFunc)) | ||
|
||
assert.Equal(fallbackVariant, *variantWithFallbackFunc) |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
||
variantWithFallbackFunc := client.GetVariant(feature, WithVariantFallbackFunc(fallbackFunc)) | ||
|
||
assert.Equal(fallbackVariant, *variantWithFallbackFunc) |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
I left a few comments. I do think the |
There could actually be a race here where a caller passes in the same pointer to multiple calls to |
@jameshartig Appreciate the review! I'll address your comments. As for touching / not touching the |
I changed the |
Yep! It looks good now. I do agree that it's unfortunate the field isn't being automatically set but that might be something we can solve down the road in a v5. |
This PR fixes a bug in how we use fallback variants in this SDK.
The fallback should be used when there is no flag, when the flag doesn't have any variants, and if the flag has variants, but is disabled. However, prior to this, it was only used if the flag didn't exist.
It addresses the issues in and closes #160.
Discussion points
Overriding
FeatureEnabled
Comparing this to the Node SDK, I noticed one thing that we don't seem to do: setting the
FeatureEnabled
property based on the flag's enabled state.Because the fallback you pass in also has
FeatureEnabled
as a property, you can in theory override this. However, that means you can get into situations where the flag is actually enabled, but the variant saysFeatureEnabled
isfalse
because that's what the fallback says. That seems incorrect to me, so I've added in some handling for that, but I'd like to get a second opinion on it.Code quality
This may be my first time writing Go, so it's very possible that I've missed some idioms or similar. Please feel free to correct as many things as you want.
This includes the very verbose test setup which accounts for ~85% of this PR.