Allow configuring HTTP timeouts

[clupprich]

Is anybody already working on allowing to configure HTTP timeouts for the Client? http allows you to do that, but it's not exposed in the configuration options of the client.

[dlitvakb]

Hey @clupprich,

Haven't considered adding this yet, there is a timeout configuration for retries on 429 failures.

Could you explain a bit further on why would you need this feature?

Cheers

[clupprich]

Hej @dlitvakb,

With the service disruption last week, we noticed that certain requests did go through to your CDN, but they took a very long time to return a response. In our situation it would have been better to fail early and set the HTTP read timeout to e.g. 5 seconds (instead of the default 60 seconds). I guess this woulnd't only be interesting for read_timeout, but also open_timeout?

Best,
Christoph

[elhu]

Hi!

We've just experienced the exact issue that @clupprich describes.
Is there any news on plans to allow timeouts to be configured?

[dlitvakb]

Hey @clupprich and @elhu,

I'll take a look into this - and try to get it into the SDK as soon as I can.

Cheers

[elhu]

@dlitvakb I gave it a quick try: #196

[teemutammela]

In the mean time, is there some best practice - or failing that, an ugly hack 😆 - for dealing with Delivery API failures? Preferably a rescue after Delivery API fails to delivery content within X amount of seconds.

[elhu]

You can always wrap the call in a https://ruby-doc.org/stdlib-2.2.0/libdoc/timeout/rdoc/Timeout.html block, but it's a very brutal way of handling this kind of things and can lead to some nasty surprises.

[teemutammela]

I wonder if rack-timeout would be of any use. My application is based on Sinatra.

[elhu]

@teemutammela if I read that correctly, this is used to terminate a request to your application, not a request your application makes to Contentful.

Depending on what you're trying to achieve, it might work as well.

[elhu]

@dlitvakb any news regarding a fix to this issue? Did you get a chance to check out #196 ?