Non-idempotent read timeouts are retried

[pkoenig10]

What happened?

A non-idempotent HTTP request was retried when the original request failed due to a read timeout.

The retried request succeeded. However the original request also eventually succeeded. This left the service in an incorrect state because an action that should have only been attempted once was performed twice.

What did you want to happen?

Requests should only be retried if either:

• The request is idempotent, according to the HTTP spec
• The request did not send any data to the server (ex. a connect timeout)

Differentiating between connect timeouts and read timeouts is currently an open issue in OkHttp:
square/okhttp#3318

Until that issue is resolved, we should bias towards the more limiting, but safe behavior of not retrying non-idempotent requests.

[zakmagnus]

I believe there are also other times when any request can be safely retried. The important property is that the remote service did not and will not do any work for that request. For example, if the remote service responds with a 503, it certainly received the request, but also certainly did no work for it (assuming it uses the response code correctly), so it's safe to retry that.

[Hazer]

square/okhttp#3318 is closed and as @swankjesse pointed out, there may be issues with proxies, QUIC and other things that are hard to be sure

[zakmagnus]

If you can't tell whether or not the server has received the request, then the correct thing to do is to not retry. Retrying a non-idempotent request is an optimization for the special case that you do know for a fact it's safe to do. If you can't tell you're in the special case, don't try to optimize.

[stale]

This issue has been automatically marked as stale because it has not been touched in the last 60 days. Please comment if you'd like to keep it open, otherwise it'll be closed in 7 days time.