Lower the value of api request timeout

[BRMatt]

At the moment the open_timeout and timeout values are 30 and 80 respectively.

On heroku they have a hard timeout of 30seconds per request, so when Stripe times out it causes the request to fail ungracefully.

I suppose an alternative would be to allow users to specify their own timeout values?

[glongman]

+1 !

[ebroder]

Hey - really really sorry for not getting back to you on this sooner. It's pretty unacceptable, and I'm looking into our processes for bindings issues to make sure it doesn't happen again.

This actually turns out to be a fairly difficult problem. We've built a "funnel" of timeouts going all the way from our bindings into the core of our infrastructure so that you can always tell whether a backend component actually failed or you just didn't get a response in time. At the narrow end of this funnel is our connection to the card networks, which usually returns responses within 0.5-1 seconds, but in some cases can take up to 30 seconds (due to the card networks, not us).

Reducing the timeout in the bindings without correspondingly adjusting the rest of our funnel creates the possibility that the bindings will time out something like a charge creation, when in fact our backend has processed it to completion (resulting in a credit card charge that your site knows nothing about).

I don't really want to drop the timeouts in our bindings in a way that's incompatible with our funnel, but it sounds like Heroku may already be doing that for us, so we probably need to come up with something. It's possible we can tighten the funnel a bit (especially now that we have some more data around how long various components take) - I'll talk about that with the rest of the team - but at least in our current state I think it's pretty unlikely we can guarantee a response in less than 30 seconds.

Does that all make sense? Do you guys have any thoughts on what we should be doing here?

[BRMatt]

Thanks for explaining that @ebroder, sounds like the problem is a bit deeper than it looks! So far we've only had 3-4 timeouts over the course of about a year, so it's not been too big of an issue; however it has the potential to cause a lot of problems. I'm not sure if heroku kills a process if it takes longer than 30seconds to respond, but obviously the user will be shown a generic error message regardless of whether the charge goes through.

Please could you let us know how the discussion with the rest of the team goes?

[timcraft]

According to the docs an error response will be returned to the user/client but the dyno will continue to process the request. So if a call to Stripe took 45s, it would presumably complete successfully, which is probably what you want in most cases. I've submitted #74 which makes these timeout values configurable.

[gavingmiller]

The other option if you're hitting stripe timeouts on heroku is to move your payment processing to a background job so that it can run without blocking your web processes. It's quite a bit more work, but makes for a better user experience on the edge cases.

[andrewpthorp]

The state of this is that the fear of lowering this (or making it configurable) might set false expectations if a user doesn't fully understand what is (or could be) happening.

Closing this issue for now. If anyone wants to discuss it further we can reopen it or you can send questions to support@stripe.com.