Net::HTTP::Persistent::Error too many connection resets

[rahim-figs]

Ruby version: 2.4.5
stripe-ruby version: 4.15.0

I recently upgraded from stripe-ruby version 3.15.0 to 4.15.0. There is a job which updates a lot of stripe subscriptions. For the last 2 days, I have been getting the following error:

too many connection resets (due to end of file reached - EOFError) after 71 requests on 67701880, last used 0.067928815 seconds ago (Net::HTTP::Persistent::Error)

Should I tweak the timeout settings?

[ob-stripe]

Hey @rahim-figs, thanks for reporting this. We're looking into it.

Could you share a simplified version of your job's code? Specifically, what API requests it's sending. Are you updating the subscriptions directly via Stripe::Subscription.update('sub_123', {...}), or are you retrieving them first via Stripe::Subscription.retrieve('sub_123'), updating attributes on the instance, then calling .save?

[rahim-figs]

Hi @ob-stripe, I am fetching the subscriptions and then calling .save on them after changing some attributes.

subscriptions.each do |subscription_id|
  stripe_subscription = Stripe::Subscription.retrieve(subscription_id)
  # Making changes here
  stripe_subscription.save
end

Thanks for looking into this.

[ob-stripe]

@brandur-stripe We briefly discussed this IRL, but to recap: I'm fairly sure this issue is caused by Net::HTTP::Persistent's own retry mechanism for GET requests: drbrain/net-http-persistent#37.

This blog post suggests that as a workaround, we could catch the error, close the connection, and retry the request. Unfortunately, I think Faraday doesn't expose a way for us to close the connection (lostisland/faraday#241). We could maybe just drop the Faraday connection entirely and create a new one, but that wouldn't work if the user is passing a custom connection object.

Any idea for how we could fix this without resorting to a larger rewrite (i.e. dropping Faraday and Net::HTTP::Persistent entirely)?

[brandur-stripe]

Any idea for how we could fix this without resorting to a larger rewrite (i.e. dropping Faraday and Net::HTTP::Persistent entirely)?

The only reasonably easy thing I can suggest is to revert Net::HTTP::Persistent as the default adapter, and broadly suggest that it shouldn't be used.

I'm kinda thinking we should just bite the bullet though and kill both Faraday and Net::HTTP::Persistent. Maybe easier said than done (every time I've changed the HTTP implementation in this library I've managed to break something despite testing unfortunately), but it's probably the right move.

[Chwistophe]

+1, using Ruby 2.5.1

Experiencing the same issue after bumping from 3.31.1 to 4.17.0 (preparing for SCA & PaymentIntents..).

It actually occurs during my "checkout" process where:

1. a PaymentIntent is initialized (API call)
2. the user takes some time to fill in the checkout fields
3. on submit page submit, PaymentIntent is confirmed manually on the server side (API call timeout here with "too many connection resets...")

Tried to tweak the Stripe.open_timeout but the error still occurs after the defined timeout.

[Medvezo]

@ob-stripe @brandur-stripe I was thinking about submitting a new issue on this topic (killing Faraday + Net::HTTP::Persistent) but thought that it might come as too arrogant and decided against it; would be great if you could pull that off though. i realize that this is not a priority for you and honestly, Net::HTTP's API isn't the greatest in the world, but consider dropping those dependencies in the future, maybe for 5.0 release (?)

[brandur-stripe]

@ob-stripe @brandur-stripe I was thinking about submitting a new issue on this topic (killing Faraday + Net::HTTP::Persistent) but thought that it might come as too arrogant and decided against it; would be great if you could pull that off though. i realize that this is not a priority for you and honestly, Net::HTTP's API isn't the greatest in the world, but consider dropping those dependencies in the future, maybe for 5.0 release (?)

Yeah, internally we're pretty much all aligned now that we want to do this. We've also got an internal issue for it, so we're tracking it there.

[alirezaseifi]

I'm also getting the following after upgrading from Stripe v3.0 to 4.19 via rspec tests
ruby v2.3

     Failure/Error:
       Stripe::Token.create(
         :bank_account => {
           :country => "US",
           :currency => "usd",
           :account_holder_name => "TEST customer bank account",
           :account_holder_type => "individual",
           :routing_number => "110000000",
           :account_number => "000123456789",
         },
       )

     ConnectionPool::Error:
       no connections are checked out
     # /home/vagrant/.bundle/xxxx/ruby/2.3.0/gems/net-http-persistent-3.0.1/lib/net/http/persistent/pool.rb:16:in `checkin'
     # /home/vagrant/.bundle/xxxx/ruby/2.3.0/gems/net-http-persistent-3.0.1/lib/net/http/persistent.rb:660:in `ensure in connection_for'
     # /home/vagrant/.bundle/xxxx/ruby/2.3.0/gems/net-http-persistent-3.0.1/lib/net/http/persistent.rb:660:in `connection_for'

How do I resolve this? The same code works perfectly on v3.0 though. I'm having this issue only in rspec. am I using any deprecated dependencies?

    stripe (4.19.0)
      faraday (~> 0.13)
      net-http-persistent (~> 3.0)
    net-http-persistent (3.0.1)
      connection_pool (~> 2.2)
    stripe (~> 4.19)

[brandur-stripe]

@alirezaseifi If you have webmock in your test stack (or any gem like it that's patching underlying HTTP adapters), you might want to try updating that too, and making sure that it's managed to find its way to a relatively current version.

Would you mind following up with [email protected] rather than here though? Especially given that this is a problem that's occurring in your test suite, it seems very likely that it's something specific to your particular configuration.

[ob-stripe]

This should be fixed stripe-ruby 5.0. The gem no longer uses Net::HTTP::Persistent at all.