This is how we are initializing the gb client

growthBookContext := growthbook.NewContext().WithAPIHost(os.Getenv("GROWTH_BOOK_API_HOST")).WithClientKey(os.Getenv("GROWTH_BOOK_SDK_KEY")).WithForcedVariations(growthbook.ForcedVariationsMap{})

	gbClient := growthbook.New(growthBookContext)
	gbClient.LoadFeatures(&growthbook.FeatureRepoOptions{
		AutoRefresh: true,
	})

Hi Pratik, To follow up on the other question you had about

WithForcedVariations

. I don't understand what the results you're expecting here are. I'll try to give some sort of explanation of what I think is going on, and you can tell me where it doesn't match what you're seeing. There are two distinct "forced" things you can do with the Go SDK (the other language SDKs behave in a similar way). You can force rules for features, which you set up on the GrowthBook site with conditions that say "if a user satisfies these conditions, then force them to have this value for this *feature*". I'm pretty sure that works correctly, since I use it for testing all the time. The

WithForcedVariations

thing is a separate mechanism that allows you to force the variation returned for an experiment. I think people mostly use it for QA purposes, since it allows you to examine what happens in your code when a particular experiment outcome happens. The code paths that reference this stuff don't influence the features that are downloaded by

LoadFeatures

and they only have an effect on experiment outcomes if the particular experiment key is in the forced variations map. Setting the forced variations map to an empty map shouldn't have any impact on anything at all. Can you confirm that you really are seeing a difference in the feature rules when you use

WithForcedVariations

? Just to give some context: Here is the code that implements

WithForcedVariations

, which just sets the forced variations map on the context: https://github.com/growthbook/growthbook-golang/blob/main/context.go#L107-L113 And here is the place where the forced variations map is referenced (in the

doRun

method which actually runs experiments and is called from

EvalFeature

) — if the map is non-empty and the experiment key is in the map, then the experiment variation (i.e. the integer index into the list of possible outcomes) is taken from the map: https://github.com/growthbook/growthbook-golang/blob/main/growthbook.go#L726-L734 Forcing of rules is handled here in

EvalFeature

— if a forcing rule exists for a user in the feature, then the forced value is returned immediately, without constructing and running an experiment for the feature (which means the forced variations map is never used in this code path): https://github.com/growthbook/growthbook-golang/blob/main/growthbook.go#L423-L444 The forced variations map isn't referenced anywhere else, so I can't see how it's possible for it to influence the effect of forcing rules. I hope this helps us get some way to understanding what's happening in your case!

My assumption is that growthbook client fetches all the features when calling

LoadFeatures

but this fetches the default values and since these are cached client doesn't know refresh values when evaluating with context with uId = x. Do you think removing explicit call to LoadFeatures() should solve the issue as features will be fetch as they are requested by clients and then they will get forced values based on evaluation context?