-
Notifications
You must be signed in to change notification settings - Fork 28
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
Add datafile isValid check in feature accessor methods #109
Add datafile isValid check in feature accessor methods #109
Conversation
lib/optimizely.rb
Outdated
@@ -343,6 +343,12 @@ def get_feature_variable_string(feature_flag_key, variable_key, user_id, attribu | |||
# Returns the string variable value. | |||
# Returns nil if the feature flag or variable are not found. | |||
|
|||
unless @is_valid | |||
logger = SimpleLogger.new |
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 see we do this an awful lot. Can we instead attach this to the Optimizely instance's @logger
if the instance is not valid and reuse that? We already instantiate a new SimpleLogger on lines 66, 75, and 82. We can attach that to the instance variable @logger and re-use throughout the code instead of instantiating every time we need to use it.
build |
…lid-datafile-for-feature-accessor
invalid_project = Optimizely::Project.new('invalid', nil, spy_logger) | ||
expect(invalid_project.get_feature_variable_boolean('boolean_single_variable_feature', 'boolean_variable', user_id, user_attributes)) | ||
.to eq(nil) | ||
expect(logger).to have_received(:log).once.with(Logger::ERROR, 'Provided datafile is in an invalid format.') |
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.
Is this right? How come we use similar messages twice?
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.
The first one comes from the initialize method. And the second one is logged in the relevant API method. Though duplicate, I think we should keep this at both places for clarity.
If a client is initialized, it should log the datafile error. When an API method is called, it should log exactly why the method is aborting.
Let me know if we should revise the error log in the API method. And shorten it to only 'Aborting "
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.
Yeah that makes sense. I agree with your assessment.
invalid_project = Optimizely::Project.new('invalid', nil, spy_logger) | ||
expect(invalid_project.get_feature_variable_double('double_single_variable_feature', 'double_variable', user_id, user_attributes)) | ||
.to eq(nil) | ||
expect(logger).to have_received(:log).once.with(Logger::ERROR, 'Provided datafile is in an invalid format.') |
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.
Shouldn't we only be logging the second message?
expect(invalid_project.get_feature_variable_integer('integer_single_variable_feature', 'integer_variable', user_id, user_attributes)) | ||
.to eq(nil) | ||
expect(logger).to have_received(:log).once.with(Logger::ERROR, 'Provided datafile is in an invalid format.') | ||
expect(logger).to have_received(:log).once.with(Logger::ERROR, 'Provided datafile is in an invalid format. Aborting get_feature_variable_integer.') |
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.
Same as above, seems redundant
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.
lgtm
Fixes #107