Supply a custom Faraday connection

[technicalpickles]

I'm using the files.upload API, and started getting this error on a few files:

Faraday::TimeoutError Net::ReadTimeout
vendor/gems/ruby/2.1.0/gems/slack-ruby-client-0.2.1/lib/slack/web/faraday/request.rb:25:in `request'
vendor/gems/ruby/2.1.0/gems/slack-ruby-client-0.2.1/lib/slack/web/faraday/request.rb:10:in `post'
vendor/gems/ruby/2.1.0/gems/slack-ruby-client-0.2.1/lib/slack/web/api/endpoints/files.rb:70:in `files_upload'

The Net::ReadTimeout is coming from using Faraday's default adapter, ie net/http. That happens when the read_timeout is exceeded, which defaults to 60 seconds http://ruby-doc.org/stdlib-2.1.1/libdoc/net/http/rdoc/Net/HTTP.html#read_timeout

It's probably not great to go past this in general, but it might be expected for large files. It should be possible to customize the read_timeout when the Faraday::Connection is constructed, but I'm not seeing any way to customize this: https://github.com/dblock/slack-ruby-client/blob/e4c39604b6d00da1e419d63db68e30032f5a08e1/lib/slack/web/faraday/connection.rb#L16-L25

I realize I'm on an older version, so I will try upgrading but I don't think that will change anything. I'm still debugging the file in question to determine how big it is, but I figured I'd drop this in case anyone runs into similar.

[technicalpickles]

https://github.com/getsentry/raven-ruby/pull/54/files is an example of adding timeouts to a faraday-based library. For even more flexibility, it might be worth exposing the connection builder during Slack.configure.

[dblock]

👍 on exposing the entire thing, maybe like Hyperclient that supports config.connection do ...? https://github.com/codegram/hyperclient. Maybe try to contribute that?

[technicalpickles]

Another approach would be to make connection not private, and memorize the object. It'd be harder to control the interface to it, but on the other hand it gives a user of the library total control of it.

[dblock]

It's seems not recommended because a lot of Faraday construction is middleware and you often can't modify the connection after-fact from what I observed in a predictable and useful way. I am open to anything that accomplishes the results we want of course :)