NoMethodError in replaced raise_error method for Faraday::Response::RaiseError

[contentfree]

Stacktrace:

/usr/local/rvm/gems/ruby-2.1.4/gems/slack-ruby-client-0.4.0/lib/slack/web/faraday/response/raise_error.rb:8:in `on_complete': undefined method `[]' for nil:NilClass (NoMethodError)
    from /usr/local/rvm/gems/ruby-2.1.4/gems/faraday-0.9.2/lib/faraday/response.rb:9:in `block in call'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/faraday-0.9.2/lib/faraday/response.rb:57:in `on_complete'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/faraday-0.9.2/lib/faraday/response.rb:8:in `call'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/faraday-0.9.2/lib/faraday/response.rb:8:in `call'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/faraday-0.9.2/lib/faraday/request/url_encoded.rb:15:in `call'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/faraday-0.9.2/lib/faraday/request/multipart.rb:14:in `call'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/faraday-0.9.2/lib/faraday/rack_builder.rb:139:in `build_response'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/faraday-0.9.2/lib/faraday/connection.rb:377:in `run_request'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/faraday-0.9.2/lib/faraday/connection.rb:177:in `post'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/slack-ruby-client-0.4.0/lib/slack/web/faraday/request.rb:25:in `request'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/slack-ruby-client-0.4.0/lib/slack/web/faraday/request.rb:10:in `post'
    from /usr/local/rvm/gems/ruby-2.1.4/gems/slack-ruby-client-0.4.0/lib/slack/web/api/endpoints/channels.rb:131:in `channels_list'

A guard needs to be added to handle the case when body isn't present

[dblock]

What is channels_list returning here? I didn't think this was ever possible - you should record a VCR output and get a test case that reproduces the problem.

[contentfree]

Don't know. Slack seems to be having intermittent issues, so maybe related (but also makes it difficult to capture/recreate). It could also be related to message throttles. Slack can return a 429 which might not have the full JSON response.

[dblock]

In this case the library should have raised an exception (the default faraday block says so, but maybe we're not handing that error code?). Either way I don't just want to throw in "protection" for a scenario we don't understand :)

[contentfree]

It does look like Faraday's own raise_error middleware should be handling anything between 400..600. Is it possible this is overwriting the mapping somehow?

[dblock]

I don't think so, but having a recorded VCR session or a test would make things easy. Can you repro this?

[contentfree]

Unable to now. It looks like Slack is back to normal and I'm unable to recreate it. But it was happening for about four hours. Weird.

[dblock]

Slack had an outage, but I don't know what form it took :(

[dblock]

Fixed in dblock@25bef46. The problem was the wrong order of Faraday middleware. It should have caught the 429 error first before processing the body at all.

[contentfree]

👍

[contentfree]

Version bump to 0.4.1?

[dblock]

@contentfree Still finalizing https://github.com/dblock/slack-ruby-client/pull/29 and want to make sure we don't release something broken that needs to be changed next again.