The above playground provides a small example of http.Get() performing a retry
under specific circumstances. This does not happen with POST requests, which can be
demonstrated by setting post to true in the playground.
What did you expect to see?
No automatic retries.
Aka seeing "HELLO WORLD!" printed exactly 3 times in all cases.
What did you see instead?
"HELLO WORLD!" printed 4 times, due to the retry of a failed request.
The retry happens only if there has been a successful request directly before it.
The text was updated successfully, but these errors were encountered:
I've realized now, that the playground that I provided often does not print the full output of the program
for some reason. You have the full output only if it prints program exited. in grey font at the bottom.
Either just run the playground again if you don't see it, or copy the code and run it locally on your machine.
Also, let me explain a bit further in words what my problem is here. I am sending requests with the default
HTTP client to a net/http server. The receiving handler func panics to cause a failure of the requests.
Now, as far as I can tell, the client is not supposed to send a retry by itself, but it does, if and only if
the previous request (possibly only to the same host, I did not test otherwise) was sucessfull.
If there was no previous request, or the previous request failed, this does not happen.
Maybe this is intended behavior, but I could not find it documented anywhere and it does seem awfully
inconsistent to me.
Transport only retries a request upon encountering a network error if the request is idempotent and either has no body or has its Request.GetBody defined. HTTP requests are considered idempotent if they have HTTP methods GET, HEAD, OPTIONS, or TRACE; or if their Header map contains an "Idempotency-Key" or "X-Idempotency-Key" entry. If the idempotency key value is a zero-length slice, the request is treated as idempotent but the header is not sent on the wire.
Thanks for pointing that out, I did not see that.
Still, I think this documentation does not exactly match what happens.
According to the documentation, in my example, I would expect more requests to retry than just one.
The example has two identical requests which encounter the same panicing handler (aka. network error?). However only
one of those requests is retried. The one which had a successful request come right beforehand.