Closed rpeng closed 4 months ago
Can you please give us an example of the issue you are receiving?
Sure thing! Basically, when we set socket level timeouts on the SmartyClient with
SmartyStreets::ClientBuilder.
retry_at_most(5).
with_max_timeout(2)
and the connection times out, for example due to hitting a slow or degraded SmartyStreet host, the client would not automatically retry because the timeout would raise a Net::OpenTimeout
or Net::ReadTimeout
. You can reproduce this by setting the max timeout to something low.
Currently, the RetrySender only retries on certain HTTP status codes, which are not set at all when there is a socket error.
From chatting with Smarty support, they mentioned it's a good practice to retry when these timeouts happen to try to hit a healthy host. This change allows socket timeout errors to be retried in the RetrySender.
Currently, timeouts are not retried as the status code is nil and the retry sender doesn't consider those as retryable errors. This change allows the client to transparently retry when a timeout error occurs at the socket level (e.g. Net::OpenTimeout and Net::ReadTimeout).