Skip to content

Fix feature variable accessor default value #113

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

Merged
merged 2 commits into from
Apr 5, 2018

Conversation

oakbani
Copy link
Contributor

@oakbani oakbani commented Apr 5, 2018

Please note that we check for 'featureEnabled' flag only in the method 'isFeatureEnabled'. So this flag makes no difference in any of the variable accessor methods.

The issue at hand was that variations, which have an empty 'variables' node, didn't get included in 'variation_variable_usage_map'. This resulted in https://github.com/optimizely/python-sdk/blob/master/optimizely/project_config.py#L435 case when detailed logs were inspected.

Changes in place:

  • Generate a key for every variation in 'variation_variable_usage_map'
  • Move log message and add additional message to provide correct and verbose logs.

@optibot
Copy link

optibot commented Apr 5, 2018

Can one of the admins verify this patch?

1 similar comment
@optibot
Copy link

optibot commented Apr 5, 2018

Can one of the admins verify this patch?

@@ -1436,7 +1436,7 @@ def test_get_feature_variable_boolean(self):

mock_logger.assert_called_once_with(
enums.LogLevels.INFO,
'Value for variable "is_working" of feature flag "test_feature_in_experiment" is true for user "test_user".'
'Value for variable "is_working" for variation "variation" is "true".'
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • feature_flag removed as we don't have feature key reference in the new method where we have moved this log message. Additionally, in logging mode logs mentioning feature keys precede this log so no need of it.
  • user_id same, not available. And the message sort of implied that selection of value somehow depends on the user ID which isn't true.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.01%) to 97.611% when pulling 05ea76e on oakbani/integer-accessor-bug into 9972c3d on master.

@coveralls
Copy link

coveralls commented Apr 5, 2018

Coverage Status

Coverage increased (+0.009%) to 97.609% when pulling 9bc9918 on oakbani/integer-accessor-bug into 9972c3d on master.

Copy link
Contributor

@thomaszurkan-optimizely thomaszurkan-optimizely left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thomaszurkan-optimizely thomaszurkan-optimizely merged commit 4fbd03b into master Apr 5, 2018
@thomaszurkan-optimizely thomaszurkan-optimizely deleted the oakbani/integer-accessor-bug branch April 5, 2018 18:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants