Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    tanaytatva
    @tanaytatva
    when I add a certain parameter in params then response come with client_error = true
    and with some params it comes nil
    Any idea about this
    Matt
    @iMacTia

    One thing I discovered is that upgrading didn't fix the issue unless I also wiped (the presumably broken) http-cache directory it had been using with 0.16.x.

    @alexjfisher I’ve already replied to you on GitHub, but for the sake of clarity a note have been added to the v0.17.0 release to highlight this :thumbsup:

    @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?
    Hi @tanaytatva, I don’t see anything wrong with your code hosnestly. Where do you see the client_error = true exactly?
    Scott P
    @anithri
    Due to things beyond my control, I need to be able to make a post request that ends in '?secretkey==' without it being changed to '?secretkey=%3d' Is that at all possible?
    Scott P
    @anithri
    Add a custom Encoder and i'm working! Thanks for the nice software.
    Matt
    @iMacTia
    Glad to hear everything is good 👍!
    rajeshwaruniversum
    @rajeshwaruniversum
    Hi How to close connection in faraday
    I tried by an object of Faraday::Connection
    by calling conn.close
    getting undefined method close which I am using version 0.17.0
    Matt
    @iMacTia
    Hi @rajeshwaruniversum, close method have just been added to master branch (not released yet) and so far has not been implemented in any adapter yet: lostisland/faraday#1069
    it’s still a WIP but hopefully will be available in the future! So I’m afraid for now you won’t be able to use it
    if you really really need it, you’ll have to use the master branch and add the close method implementation to the adapter you’re using
    Hope that helps
    rajeshwaruniversum
    @rajeshwaruniversum
    Hi Thanks for your comment
    that make sence
    I took master branch
    but how to add a close method to my adapter
     Faraday::Connection.new(url: url) do |faraday|
          faraday.request  :url_encoded
          faraday.response :logger
          faraday.adapter  Faraday.default_adapter
        end
    Matt
    @iMacTia
    You’ll have to monkey patch the adapter and implement the method. If you’ve never monkey-patched, this is a good start: https://www.justinweiss.com/articles/3-ways-to-monkey-patch-without-making-a-mess/
    The aim is to add the method close to whichever adapter you’re using (default is Net::HTTP) and in that method, close the connection
    rajeshwaruniversum
    @rajeshwaruniversum
    Thanks will have look on this
    Rachel Lanman
    @RSR312-206
    does anyone know of a good way to test the retry option? Is there a way to see if an endpoint ends up being retried, and how many times?
    Matt
    @iMacTia
    Depending on how you configured it (under which circumstances it should retry) then it might be easier or not. If we’re talking about unit tests then webmock is probably your best shot :)
    Rachel Lanman
    @RSR312-206
    @iMacTia it was just to see if it was working - not in a unit test. I see there is a retry_block which I was thinking I could write the env.status to a tmp file. Mainly just trying to get some feedback that it's working.
    Matt
    @iMacTia
    Oh I see what you mean now! Yes that’s a good way to spot when requests have been retried :). You could also add the logger middleware to your stack, AFTER the retry middleware, to see multiple logs of the same request
    Rachel Lanman
    @RSR312-206
    is the logger middleware available on version 0.12.2?
    because retry_block is not
    Matt
    @iMacTia
    Ah right, the latter it was introduced later.
    Yes, logger middleware has been around for years
    So pretty sure it’s available
    Rachel Lanman
    @RSR312-206
    cool - thank you
    side note, I can't upgrade faraday because omniauth-stripe-connect has a dependency which requires a version of Faraday less than 0.13.
    which is really annoying
    Matt
    @iMacTia
    Interesting, not sure why they’d put such a limitation...
    Rachel Lanman
    @RSR312-206
    yeah I haven't had time to dig into why
    joznt
    @joznt
    Hello guys, someone can enlighten me in one problem?, I'm trying to use Faraday to interact with a API from one of our company, the problem is, the API URL is "http://server/selled?startDate=2020-01-01T00:00:00-03:00&endDate=2020-01-01T23:59:59-03:00&categoryID=9878&sellerID=4645" and I'm having trouble when the URL is encoded
    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)
    Matt
    @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
    Matt
    @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
    Matt
    @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?