Hi there! :wave: We're working with the growthboo...
# announcements
k
Hi there! šŸ‘‹ We're working with the growthbook python sdk and we found an unexpected behaviour. Let me address it and share the details in the thread below: šŸ‘‡
feature list.js
Given the feature list JSON above
And the following python code that: ā€¢ implements a callback function that just print the info ā€¢ implements a for loop that iterates over a range of integer values for the
shopper_id
ā€¢ and fixed the
company_id
to a specific value
python_code.py
It doesn't return any output, when the expected output would be forcing the
bar
variation
However, when changing the fixed
company_id
to "2", then it returns the following output
We've tried also with different configurations, but always it seems that the condition rule to force specific variants is not working as expected (Mentioning also some team members: @elegant-flag-19390 @green-jordan-83609)
f
The trackingCallback only runs for experiments, so if the value was forced from a non-experiment rule it will not be called.
The idea is that you would use force rules to exclude some people from the experiment and assign them specific values. And then, for the people who are part of the experiment, they would be randomly assigned and you would track the exposure.
šŸ‘ 1
k
I believe we have configured it properly, check out this screenshot
f
Only the first matching rule is used. So that first "force" rule is stopping people from continuing on and being part of the experiment.
k
ok @future-teacher-7046 the point you mentioned makes lot of sense So then, how the python code knows when forcing values which flow/variant should be used? Maybe, from the feature list JSON?
for instance in this case, the forced value is
bar
when the condition applies
f
You would fork your code based on the value of the feature, and not the variant number.
Copy code
feature = gb.evalFeature("feature_force_value")
if feature.value == "bar"
  ...
That way your code doesn't care if the value comes from an experiment or is forced. If you stop the experiment, you don't need a new code commit.
Since you're using a string as the feature value instead of boolean, the
isOn
and
isOff
methods aren't that useful since every string value (besides an empty string) will be considered "on".
k
Totally understood, now everything is clear from our side. We could use this
getFeatureValue
and also this
evalFeature
Thanks so much for the clarifications and the quick response. šŸ˜