Join GitHub today
Fix connect timeout not being enforced #9329
The loop was catching the timeout exception that should stop execution, so the next IP would no longer be within a timed block, which led to requests taking much longer than 10 seconds.
Regression from #6813
Now, the total timeout is 1 second for DNS look-up, and 10 seconds for socket opening, wherein 2 IPs are tried one after the other within those 10 seconds. So if there is only one IP, we wait 10 seconds, if there's two IPs, we wait 5 seconds each.
Yeah, doing it on the full block is probably best. The downside of this PR is that it's fixing reachability to one set of broken instances while breaking reachability to another set of broken instances.
I'd oppose merging this until it can be properly fixed, but, well, too late now.
Ah, mis-read "approved" as "merged", apologies. It's 10am on a holiday and the coffee hasn't come out yet, heh.
For smaller instances, the timeouts are less of a problem than deliverability. RedLight kicks in pretty quickly for AP endpoints and limits the overall performance impact for complete unreachability pretty well, but whenever OVH or Scaleway half-break for a few hours, not falling back to legacy IP is a problem.
Nov 22, 2018
11 checks passed
I noticed that this change is causing a change in address family preference, I noticed mastodon.social switching over to IPv4 for outbound federation as opposed to using IPv6 preferred if available.
18.104.22.168 - - [22/Nov/2018:22:57:32 +0000] "POST /inbox HTTP/1.1" 202 36 "-" "http.rb/3.3.0 (Mastodon/2.6.1; +https://mastodon.social/)"
That seems to be a regression, is this some sort of default behaviour in Resolv::DNS, if so can we change this behaviour?