More http client option mysteries: Timout options in rich media don't seem to work
Maybe related to #2101 (closed).
IRC discussion:
<@rinpatch> okay, failure tracking + parallel fetching brings the worst case (20 posts with httpbin.org/delay/5) linked down to 10 seconds from 1m+
<@rinpatch> still wondering why it's not, well, 5 seconds
<lain_soykaf> sounds like it's called twice
<lain_soykaf> if you delay for longer, is the resulting time always twice as long?
<@rinpatch> let me see
<@rinpatch> I am surprised it's even that long tbh, we set rich media requests to time out after 2s
<@rinpatch> that's on hackney, let's see if it's the same on gun
<lain_soykaf> i somewhat suspect that our hackney options don't work...
<@rinpatch> 5s on gun
<@rinpatch> may be
<@rinpatch> okay tried posting 20 startuses with each being httbin.org/delay/{1..20}
<@rinpatch> still 5s
<lain_soykaf> sounds like a 5s timeout and not a 2s timeout
<alexs7> 5s on gun or hackney?
<@rinpatch> gun
<@rinpatch> tested with failure tracking but without parallel fetching, went over a minute again. so it's certainly an improvement
<alexs7> 5s is default gun timeout (if no timeout is set for pool), did you pull http fixes? without them adapter options are not working, which are set in parser module
<@rinpatch> yup, I did. my branch is based on https://git.pleroma.social/pleroma/pleroma/-/commit/47ff425cfd53212aba26e9eba86de16e3ef1442b
<@rinpatch> tried the same 1..20 delay test with hackney, also still 10s. so I guess it's just default timeouts
<alexs7> can you check what adapter options are transfered to tesla in `lib/pleroma/http/http.ex:63` in gun and hackney? maybe there is one more bug with options...
<@rinpatch> one moment
<@rinpatch> timeout: 10000
<@rinpatch> that's on gun, I guess it's 5s because we have await_up_timeout: 5000
<@rinpatch> for hackney it is connect_timeout: 10_000, recv_timeout: 2000