Skip to content

Conversation

@choran
Copy link
Member

@choran choran commented Oct 4, 2017

Resolving conflicts for PR #264 and adding unit tests.
Also updating some other tests due to warnings

Gemfile Outdated
gemspec
%w[rspec rspec-core rspec-expectations rspec-mocks rspec-support].each do |lib|
gem lib, :git => "git://github.com/rspec/#{lib}.git", :branch => 'master'
end

Choose a reason for hiding this comment

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

Are we using rspec anywhere? Thought the tests here are running via mocha.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, initially I thought test was failing due to missing rspec dependency but like you said, turns out it was mocha so can remove this

require 'webmock'
include WebMock::API

WebMock.enable!
Copy link

@sureshs592 sureshs592 Oct 5, 2017

Choose a reason for hiding this comment

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

Can we shift these imports + configuration into the spec_helper file? webmock can come in handy for other tests in the future.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I was initially unsure whether to put it in spec_helper file in case it impacted other tests but will do it now. It should not impact other tests

raise_errors_on_failure(response)
parsed_body
rescue Intercom::RateLimitExceeded => e
if @handle_rate_limit

Choose a reason for hiding this comment

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

We'll need a max retry mechanism here. Unlikely scenario but we can risk running into an infinite loop if we don't have one.

Copy link
Member Author

Choose a reason for hiding this comment

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

makes sense, any suggestion on max retry? 10 or 20 or something like that?

Choose a reason for hiding this comment

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

Yup. We wait for a fair bit here so I would go with something small like 3. This operation risks getting too long otherwise. Thoughts @mmartinic ?

Copy link
Member

Choose a reason for hiding this comment

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

3 sounds good. we can make this configurable later

end

def execute(target_base_url=nil, username:, secret: nil)
retries ||= 3
Copy link
Member

Choose a reason for hiding this comment

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

this is outside of try block. we can just do retries = 3

Copy link
Member Author

@choran choran Oct 6, 2017

Choose a reason for hiding this comment

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

Yeah, initially i had it in the try block but moved it outside and forgot to change it

README.md Outdated
#=> {:limit=>180, :remaining=>179, :reset_at=>2014-10-07 14:58:00 +0100}
```

You can handle the rate limits yourself but a simply option is to use the handle_rate_limit flag.

Choose a reason for hiding this comment

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

Small typo. simply --> simple

@choran
Copy link
Member Author

choran commented Oct 6, 2017

@sureshs592 nice catch ! updated that now, do you think this is ok to go now?

@choran
Copy link
Member Author

choran commented Oct 6, 2017

@sureshs592 set the rate limit flag in the init function now to make it clear what the default is

sureshs592
sureshs592 previously approved these changes Oct 6, 2017
@choran choran merged commit 7296765 into master Oct 6, 2017
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