slack-ruby-client
slack-ruby-client copied to clipboard
Supply a custom Faraday connection
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.
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.
:+1: on exposing the entire thing, maybe like Hyperclient that supports config.connection do ...? https://github.com/codegram/hyperclient. Maybe try to contribute that?
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.
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 :)