Faraday::ConnectionFailed often raises

[a-ta-ta]

Situation: I'm settling news feed in development. Of course I do that with a free plan account with low priority queue. When news sent first time or no news were sent for some time, I get Faraday::ConnectionFailed - execution_expired. After inspecting the sending method with byebug for some time (~ 15-30 seconds) it magically disappears.

[a-ta-ta]

Tried to change default timeout as option like:

@client = Stream::Client.new('id', 
'your_api_key', 
location: 'your_location',
default_timeout: 10000)

But still issue often comes up

[dssjoblom]

I'm having the same problem. Is there something that can be done to alleviate this? For example, in a batch job that updates a few thousand items, with every item accessing getstream, some percentage of the requests fail (maybe 2-3% which sounds really high). There is no concurrency in this job, it is just one request following another, so it seems unlikely it would overload the server. I also don't think it is related to rate limits, because the requests fail randomly, one request fails, but the one immediately after it succeeds.

Is this an issue in the backend or in the gem?

[a-ta-ta]

Hey, @dssjoblom! Really dunno where is the problem, my guess is the backend. However, I resolved the issue in such way:

    gfm = FeedManager.new
        target_feed = gfm.get_feed(model, id)
        news_feed = gfm.get_feed('timeline_aggregated', user_id)
        begin
          news_feed.unfollow(target_feed.slug, id)
        rescue Faraday::ConnectionFailed
            retry
        end

Hope that helps you too!

[ferhatelmas]

@dssjoblom @a-ta-ta

First usual suspects:

0. Set the location where your application is used. Otherwise, proxied to correct region, unnecessary latency.
1. Set a reasonable default_timeout in the client according to your network and geography.

Then, could you please share some API keys and time range you saw this error(s)? I would like to investigate backend logs. I hardly guess issue is in backend but let's scope the problem.

When we are certain about the issue location, we can tune faraday.

[dssjoblom]

@a-ta-ta

It does not, unfortunately, but thank you anyway. I'm also using retries to work around this issue, but it is not sufficient since it also affects end-user clients. Users won't wait for more than a few seconds.

@ferhatelmas

This is the configuration I'm using:

Stream::Client.new( Rails.application.secrets.getstream_key,
                        Rails.application.secrets.getstream_secret,
                        nil,
                        location: Rails.application.secrets.getstream_location,
                        default_timeout: 6 ) # Increase default timeout, default is 3 secs

, where getstream_location is eu-central. I also sent a bug report via your website, and according to the contact person there, you were already aware of the issue. You should be able to get the API keys from them (Seni), I'm a bit uncomfortable pasting them on a public forum. I'll attach a detailed log of when this happened last time below, and it is also easily reproducible if need be.

item_tags.log

Most of the lines are simply item id, followed by "done", which indicates success. The lines with WARN or ERROR are failures. In the case of ERROR, the code has already retried the request several times over a span of minutes.

[peterdeme]

https://github.com/GetStream/stream-ruby/pull/136