4 x connectandsend() retries in call to HTTP.request(..., retries = 0)

[samoconnor]

HTTP.jl/src/client.jl

Line 322 in 0bb79a7

conn = @retryif ClosedError 4 connectandsend(client, sch, host, ifelse(p == "", "80", p), req, opts, verbose)

Should be @retryif ClosedError retry connectandsend(... ?

Also, there are other places in client.jl where network connect, read, write etc is retried despite retries = 0:

HTTP.jl/src/client.jl

Line 189 in 0bb79a7

ip = @retry Base.getaddrinfo(hostname)

HTTP.jl/src/client.jl

Line 191 in 0bb79a7

tcp = @retryif Base.UVError @timeout(opts.connecttimeout::Float64,

HTTP.jl/src/client.jl

Line 234 in 0bb79a7

@retryif Base.UVError write(conn.socket, reqstr)

HTTP.jl/src/client.jl

Line 271 in 0bb79a7

buffer = @retry @timeout(tm, readavailable(socket), error("read timeout"))

[samoconnor]

@quinnj, I started on a PR for this, but the problem is that there are nested retries.
The doc says: "retries::Int: # of times a request will be tried before throwing an error; default = 3".
If I just use the retry::Int arg of request() for the @retryif ClosedError retry parameter we might end up with more than the requested number of retries. i.e. there could be 3 connectandsend() attempts and another 3 attempts at whatever comes after that that is already governed by retry::Int.

Perhaps it would be cleaner to take out all the low-level retries and have a single top-level retry loop governed by retry::Int.

[quinnj]

I'm not sure I really see the issue; I don't see a problem w/ hard-coding a retry for Base.getaddrinfo; is it really terrible if that gets auto-retried? What's the use-case for not allowing that retry? I imagine your use-case comes more from wanting complete control over all retrying, but in this case, I feel like it's just a no-brainer and can't hurt to just do the retry in HTTP.jl itself. I'd like to hear more specific issues/use-cases around having this kind of super granular retry control.