fix: variant fallback usage #171

thomasheartman · 2023-12-18T10:36:57Z

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 says FeatureEnabled is false 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.

thomasheartman · 2023-12-18T10:44:05Z

client.go

-	if !f.Enabled {
-		return defaultVariant


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.

client_test.go

chriswk

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.

👍

config.go

@@ -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


jameshartig · 2023-12-18T20:36:53Z

client_test.go

+
+	fallbackVariant := api.Variant{
+		Name: "fallback-variant",
+                FeatureEnabled: true,


Spacing is a bit weird here

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.

jameshartig · 2023-12-18T20:37:42Z

client_test.go

+
+	variantWithFallbackFunc := client.GetVariant(feature, WithVariantFallbackFunc(fallbackFunc))
+
+	assert.Equal(fallbackVariant, *variantWithFallbackFunc)


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)

Removed changing the feature enabled in 251d167 as per your suggestion. With that change, is there still anything here you'd like to address?

client_test.go

+
+	variantWithFallbackFunc := client.GetVariant(feature, WithVariantFallbackFunc(fallbackFunc))
+
+	assert.Equal(fallbackVariant, *variantWithFallbackFunc)


client_test.go

+
+	variantWithFallbackFunc := client.GetVariant(feature, WithVariantFallbackFunc(fallbackFunc))
+
+	assert.Equal(fallbackVariant, *variantWithFallbackFunc)


jameshartig · 2023-12-18T20:40:02Z

I left a few comments. I do think the FeatureEnabled overriding makes sense but since it is a pointer it's a bit risky. There definitely needs to be something in those method docs that makes it very clear that the pointer will be modified.

jameshartig · 2023-12-18T20:43:14Z

There could actually be a race here where a caller passes in the same pointer to multiple calls to GetVariant and that ends up triggering a race when setting that field. Because of this possible race I'm actually leaning the other way now and maybe think we should just return it as-is (without touching the variant) at least until we have a solution for the race. @thomasheartman @chriswk thoughts?

thomasheartman · 2023-12-19T09:43:39Z

@jameshartig Appreciate the review! I'll address your comments. As for touching / not touching the FeatureEnabled field. Yeah, that's a good point, which is why I was a little wary of it. Because we're dealing with pointers here (as far as I can tell), it makes it trickier to return a struct with just that field overridden. I'm happy to leave out changing the FeatureEnabled field (but I think that should also be clarified in the function comments and the docs).

thomasheartman · 2023-12-19T10:36:25Z

I changed the FeatureEnabled handling in 251d167 and added some extra tests for that explicitly in bc87bd3. Does that seem sensible to you @jameshartig? Oh, and I'd be very interested to hear your thoughts on that handling as well, @chriswk ☺️

jameshartig · 2023-12-19T16:11:26Z

I changed the FeatureEnabled handling in 251d167 and added some extra tests for that explicitly in bc87bd3. Does that seem sensible to you @jameshartig? Oh, and I'd be very interested to hear your thoughts on that handling as well, @chriswk ☺️

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.

fix: add tests and impl

6bdcac9

thomasheartman mentioned this pull request Dec 18, 2023

[wip] fix: variant fallback usage #169

Closed

fix: update comments

937df2b

thomasheartman requested a review from chriswk December 18, 2023 10:40

thomasheartman mentioned this pull request Dec 18, 2023

WithVariantFallback and WithVariantFallbackFunc are called when feature isn't found #160

Closed

thomasheartman commented Dec 18, 2023

View reviewed changes

fix: minor rename

c99a893

chriswk reviewed Dec 18, 2023

View reviewed changes

client_test.go Outdated Show resolved Hide resolved

chriswk approved these changes Dec 18, 2023

View reviewed changes

jameshartig reviewed Dec 18, 2023

View reviewed changes

client_test.go

variantWithFallbackFunc := client.GetVariant(feature, WithVariantFallbackFunc(fallbackFunc))

assert.Equal(fallbackVariant, *variantWithFallbackFunc)

This comment was marked as resolved.

Sign in to view

jameshartig reviewed Dec 18, 2023

View reviewed changes

client_test.go

variantWithFallbackFunc := client.GetVariant(feature, WithVariantFallbackFunc(fallbackFunc))

assert.Equal(fallbackVariant, *variantWithFallbackFunc)

This comment was marked as resolved.

Sign in to view

thomasheartman added 4 commits December 19, 2023 11:19

fix: use noopListener

d4a5c32

fix: don't change the "FeatureEnabled" state of the fallback variant

251d167

Chore: remove empty struct from list

d725015

Test: ensure that the fallback variant's FeatureEnabled is unchanged

bc87bd3

Docs: add notes about FeatureEnabled to function docs

12e10a4

jameshartig approved these changes Dec 19, 2023

View reviewed changes

thomasheartman merged commit 4081ef8 into v4 Dec 21, 2023
8 checks passed

thomasheartman deleted the fix/variant-fallbacks branch December 21, 2023 07:54

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: variant fallback usage #171

fix: variant fallback usage #171

thomasheartman commented Dec 18, 2023 •

edited

Loading

thomasheartman Dec 18, 2023

chriswk left a comment

This comment was marked as resolved.

jameshartig Dec 18, 2023

thomasheartman Dec 19, 2023

jameshartig Dec 18, 2023

thomasheartman Dec 19, 2023

jameshartig Dec 19, 2023

This comment was marked as resolved.

This comment was marked as resolved.

jameshartig commented Dec 18, 2023

jameshartig commented Dec 18, 2023

thomasheartman commented Dec 19, 2023

thomasheartman commented Dec 19, 2023

jameshartig commented Dec 19, 2023


		variantWithFallbackFunc := client.GetVariant(feature, WithVariantFallbackFunc(fallbackFunc))

		assert.Equal(fallbackVariant, *variantWithFallbackFunc)

fix: variant fallback usage #171

fix: variant fallback usage #171

Conversation

thomasheartman commented Dec 18, 2023 • edited Loading

Discussion points

Overriding FeatureEnabled

Code quality

thomasheartman Dec 18, 2023

Choose a reason for hiding this comment

chriswk left a comment

Choose a reason for hiding this comment

This comment was marked as resolved.

jameshartig Dec 18, 2023

Choose a reason for hiding this comment

thomasheartman Dec 19, 2023

Choose a reason for hiding this comment

jameshartig Dec 18, 2023

Choose a reason for hiding this comment

thomasheartman Dec 19, 2023

Choose a reason for hiding this comment

jameshartig Dec 19, 2023

Choose a reason for hiding this comment

This comment was marked as resolved.

This comment was marked as resolved.

jameshartig commented Dec 18, 2023

jameshartig commented Dec 18, 2023

thomasheartman commented Dec 19, 2023

thomasheartman commented Dec 19, 2023

jameshartig commented Dec 19, 2023

thomasheartman commented Dec 18, 2023 •

edited

Loading

Overriding `FeatureEnabled`