Skip to content
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

Merged
merged 3 commits into from
Jun 21, 2018

Conversation

oakbani
Copy link
Contributor

@oakbani oakbani commented Jun 14, 2018

Fixes #107

@oakbani oakbani requested a review from mikeproeng37 June 14, 2018 10:16
@coveralls
Copy link

coveralls commented Jun 14, 2018

Coverage Status

Coverage remained the same at 100.0% when pulling 0e2e885 on rashid/invalid-datafile-for-feature-accessor into c1f1154 on master.

@@ -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
Copy link
Contributor

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.

@mikeproeng37
Copy link
Contributor

build

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.')
Copy link
Contributor

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?

Copy link
Contributor Author

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 "

Copy link
Contributor

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.')
Copy link
Contributor

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.')
Copy link
Contributor

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

Copy link
Contributor

@mikeproeng37 mikeproeng37 left a comment

Choose a reason for hiding this comment

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

lgtm

@mikeproeng37 mikeproeng37 merged commit 92f4efd into master Jun 21, 2018
@oakbani oakbani deleted the rashid/invalid-datafile-for-feature-accessor branch June 22, 2018 07:06
@oakbani oakbani restored the rashid/invalid-datafile-for-feature-accessor branch June 22, 2018 07:06
@oakbani oakbani deleted the rashid/invalid-datafile-for-feature-accessor branch June 22, 2018 07:07
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.

4 participants