by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matheus Santana
    @embs

    @embs sorry I missed your message! I’m trying to reproduce that issue on my Mac but I see a normal Faraday::ConnectionFailed exception being raised. Could you provide some additional information about your OS and if there’s something listening to that port?

    @iMacTia no problem. Thanks for your help! I was able to investigate this further and could reliably reproduce it when running on Docker.

    The problem seems to have been fixed in v1.

    If we build two docker images, say faraday-get-localhost:0.17.3 with a Dockerfile such as

    FROM ruby:2.5.3-slim
    
    RUN gem install faraday -v 0.17.3
    
    CMD ruby -e "require 'faraday'; p Faraday::VERSION; Faraday.get('http://localhost:9875')"

    and another image for v1:

    FROM ruby:2.5.3-slim
    
    RUN gem install faraday
    
    CMD ruby -e "require 'faraday'; p Faraday::VERSION; Faraday.get('http://localhost:9875')"

    Then when we run 0.17.3 we get an EADDRNOTAVAIL:

    $ docker run faraday-get-localhost:0.17.3
    "0.17.3"
    /usr/local/lib/ruby/2.5.0/net/http.rb:939:in `rescue in block in connect': Failed to open TCP connection to localhost:9875 (Cannot assign requested address - connect(2) for "localhost" port 9875) (Errno::EADDRNOTAVAIL)
            from /usr/local/lib/ruby/2.5.0/net/http.rb:936:in `block in connect'
            from /usr/local/lib/ruby/2.5.0/timeout.rb:93:in `block in timeout'
            from /usr/local/lib/ruby/2.5.0/timeout.rb:103:in `timeout'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:935:in `connect'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:920:in `do_start'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:909:in `start'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:1455:in `request'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:1213:in `get'
            from /usr/local/bundle/gems/faraday-0.17.3/lib/faraday/adapter/net_http.rb:85:in `perform_request'                                                                                    
            from /usr/local/bundle/gems/faraday-0.17.3/lib/faraday/adapter/net_http.rb:43:in `block in call'                                                                                      
            from /usr/local/bundle/gems/faraday-0.17.3/lib/faraday/adapter/net_http.rb:92:in `with_net_http_connection'                                                                           
            from /usr/local/bundle/gems/faraday-0.17.3/lib/faraday/adapter/net_http.rb:38:in `call'
            from /usr/local/bundle/gems/faraday-0.17.3/lib/faraday/request/url_encoded.rb:15:in `call'                                                                                            
            from /usr/local/bundle/gems/faraday-0.17.3/lib/faraday/rack_builder.rb:143:in `build_response'                                                                                        
            from /usr/local/bundle/gems/faraday-0.17.3/lib/faraday/connection.rb:387:in `run_request'                                                                                             
            from /usr/local/bundle/gems/faraday-0.17.3/lib/faraday/connection.rb:138:in `get'
            from /usr/local/bundle/gems/faraday-0.17.3/lib/faraday.rb:102:in `method_missing'
            from -e:1:in `<main>'

    But when running v1 we get a proper Faraday::ConnectionFailed:

    $ docker run faraday-get-localhost:1.0
    "1.0.0"
    /usr/local/lib/ruby/2.5.0/net/http.rb:939:in `rescue in block in connect': Failed to open TCP connection to localhost:9875 (Cannot assign requested address - connect(2) for "localhost" port 9875) (Faraday::ConnectionFailed)
            from /usr/local/lib/ruby/2.5.0/net/http.rb:936:in `block in connect'
            from /usr/local/lib/ruby/2.5.0/timeout.rb:93:in `block in timeout'
            from /usr/local/lib/ruby/2.5.0/timeout.rb:103:in `timeout'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:935:in `connect'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:920:in `do_start'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:909:in `start'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:1455:in `request'
            from /usr/local/lib/ruby/2.5.0/net/http.rb:1
    Matheus Santana
    @embs
    Additional info:
    • Docker version 19.03.5, build 633a0ea838
    • Host OS: Debian 10
    • Linux kernel: 4.19.0-6-amd64
    • Nothing listening on the tested port (neither in the host nor in the container)
    Mattia
    @iMacTia
    Thanks for the follow-up @embs. This is really useful because it means we somehow fixed it in 1.0, but there are so many differences that it won’t be an easy search 😓
    Matheus Santana
    @embs
    @iMacTia will the 0.Y.Z releases continue to receive bugfixes or is anyone willing to get new bugfixes required to upgrade to 1.0? In other words, is it desirable to have this fix "backported" to 0.Y.Z releases?
    Matheus Santana
    @embs
    This might be the missing bit: lostisland/faraday@148b99e
    Mattia
    @iMacTia
    We definitely don’t want to release a 0.18 version, but security and bug fixes can still be released for 0.17
    Thanks for having a look and identifying the possible fix. Feel free to open a PR or I’ll have a look as soon as I can
    As far as the change is backwards compatible, we can definitely back port it as a bugfix
    Mattia
    @iMacTia
    @joznt could you please open an issue in GitHub with additional details?
    Matheus Santana
    @embs
    @iMacTia what's the branch such a PR should target? 0.1x?
    Mattia
    @iMacTia
    @embs correct!
    Corentin
    @Frenchcooc
    Hi! I'm totally new here. Really don't want to bother. I'm a developer advocate at Bearer.sh. I'm wondering if the "Faraday Team" is open to sponsorship? And if so, who would be the best person to talk to? Thanks 🙏
    Mattia
    @iMacTia
    Hi @Frenchcooc, I’ll raise this with the rest of the core team and get back to you. We’re aware GitHub has recently launched a “donations” feature but we haven’t discussed about it yet
    What we definitely don’t want to do is to have a “PRO” version of Faraday or different support levels. Faraday fully embraces the OSS principles and will never make distinctions between developers
    Corentin
    @Frenchcooc
    Thanks @iMacTia! Definitely not looking into adding "PRO" version here. More about supporting the project and adding logo/link to the sponsor website. Let me know
    Srikanth Tanneeru
    @stanneeru
    Faraday::ConnectionFailed (execution expired)
    I am having this issue
    Matheus Santana
    @embs
    Hello @stanneeru. What is the address you're trying to access? I think this error may be thrown when the address is unavailable.
    KazeEnji
    @KazeEnji
    hello everyone. i'm trying to get faraday running for the first time on a Kali 2020.1 VM and it won't let me login. I tried changing the password when it ran and it said the information was incorrect. I then also tried changing the password using faraday-manage change-password and it still won't let me log in. Any idea what I might be doing wrong?
    KazeEnji
    @KazeEnji
    hello everyone. i'm trying to get faraday running for the first time on a Kali 2020.1 VM and it won't let me login. I tried changing the password when it ran and it said the information was incorrect. I then also tried changing the password using faraday-manage change-password and it still won't let me log in. Any idea what I might be doing wrong?
    KazeEnji
    @KazeEnji
    is anyone online who can help?
    Matheus Santana
    @embs

    Hey there @KazeEnji.

    I was unable to understand your question, sorry. I'm not aware of any faraday-manage command regarding the Ruby Faraday library.

    A search quick for "faraday-manage" led me to https://github.com/infobyte/faraday, which is not the project related to this chat. This Gitter relates to https://github.com/lostisland/faraday/

    Maybe you're in the wrong chat?

    KazeEnji
    @KazeEnji
    Hey @embs Thanks for getting back to me. Is this not the faraday chat for the Faraday IPE built into Kali? I got into this chat from the Faraday website...
    KazeEnji
    @KazeEnji
    my apologies then @embs et all. I don't know how i got into the wrong chat from the faraday website haha.
    Matheus Santana
    @embs
    Hahahah. No worries @KazeEnji. Nice to meet you. :)
    André Diego Piske
    @andrepiske
    hello everyone! I saw latest Faraday drops jruby and rubinius support. Why is that? Is it lack of maintainers, or maybe a design decision? -- just asking, not demanding anything here at all :)
    I searched github issues and couldn't find anything for the reason
    Mattia
    @iMacTia
    Hi @andrepiske, totally legit question! The main issue for us was that more and more JRuby/Rubinius tests and dependencies were quickly failing, especially after running updates across the line for the Faraday v1.0 release. We had some great contributors over time that introduced JRuby support, but none of them settled as a maintainer, and so keeping support for other rubies was becoming a huge burden on the core team.
    This doesn’t mean Faraday doesn’t work with them, or that we don’t want their support in the code anymore.
    It simply means we can’t afford to officially support them, mainly for lack of knowledge.
    We do however welcome maintainers (not contributors, hence on a regular basis) that would like to help us reintroducing and supporting these rubies
    Olle Jonsson
    @olleolleolle
    What we can do: Any JRuby defect logged, or any use-case with JRuby trouble, we can accommodate in the GitHub Issues issue tracker, and inform JRuby people about.
    Mattia
    @iMacTia
    👍👍
    André Diego Piske
    @andrepiske
    @iMacTia Thanks for the explanation. As I said, I just wanted to know the motivation behind it. I thought it would probably be due to lack of contributors.
    John Manoogian III
    @jm3
    :wave:
    anyone have any experience updating old gems dependent on an old version of faraday that's now throwing lots of deprecation errors? I have an old half-finished app I was playing with that uses the wayback (as in archive.org) gem, and I'm a little stuck. I updated the faraday + faraday middleware versions, and now it looks like the next step will be porting some code that uses Faraday::Builder to <whatever the new syntax is>. Are there any reference examples I could take a look at to understand what I might need to change to make this gem work with latest Faraday?
    (wayback's last release that i forked was dependent on faraday 0.9.2)
    Mattia
    @iMacTia
    Hey @jm3, welcome to the channel. If the deprecation message comes from Faraday, then we usually also indicate how to fix it. I’m wondering if the ones you see are coming from a ruby/faraday combo instead.
    Feel free to open an issue in the GitHub repo with more details about the warnings you’re seeing and we’ll be happy to have a look
    Apart from that, all versions after 0.9.2 (including the latest 1.0.x) are supposed to be fully backwards-compatible, so you should be able to update to the latest, as far as you use Ruby 2.4+
    Moneer
    @barhum
    Any proper way to rescue a connection error in Faraday if post fails? I am using the following response = Faraday.post('url', converted_hash)
    Mattia
    @iMacTia
    @barhum can’t think of any better way than wrapping that into a begin/rescue block. Are you in any particular situation where that might not be the best approach?
    Tim Wisniewski
    @timwis
    Hey, I'm trying to create a "service" (external rest api wrapper) in rails. Does anyone have an example of this? In particular, it requires an API key, so I'd prefer to just initialise it once
    Mattia
    @iMacTia
    Hey @timwis, this sounds like the perfect use case for Faraday. There’s no generic guide or way to do it as it depends on how you need to provide the API Key to the server. You can checkout our site (https://lostisland.github.io/faraday/) and particularly how to customise your request, to get started. You’re most probably looking to set a default header on all requests and can do so by passing it to your connection initializer.
    Checkout the section “The Connection Object” at the bottom of this page: https://lostisland.github.io/faraday/usage/
    The example shows you how to set the content-type header for all requests, you can apply the same strategy to set the header for your API key
    Tim Wisniewski
    @timwis
    Thanks. I think I’m just not super familiar with where I’d initialise it in a rails context if it’s used by multiple controllers. Seems redundant to initialise it multiple times with the same api key
    Mattia
    @iMacTia
    Of course! maybe the easiest way is to create a class (Client) which initialises the connection, then use a Rails initialiser to store an instance of the client in the Rails.application.config. You’ll then be able to access it from anywhere in your app
    Erik Jacobs
    @thoraxe
    I am trying to use Faraday with webmock but I think I'm having an issue with using a connection object. However I want to use Faraday::Response::RaiseError to simplify handling problems. Is there a way to use Faraday::Response::RaiseError without a connection object?
    bblimke/webmock#894 describes my code and what's going on
    Erik Jacobs
    @thoraxe
    ok i think the connection object is a red herring, because I switched to trying to use excon and had the same issue. I think this is a webmock+sidekiq problem.
    Mattia
    @iMacTia
    @thoraxe I hope you managed to fix your issue in the meantime, but if not, then reest assured I used the Faraday-Webmock pair A LOT in the past with no issues. Actually, if you check the Faraday repository you’ll see that Faraday tests are written using WebMock :smiley: !
    If you’re still experiencing issues and believe it’s related to Faraday, please feel free to share an I can have a look