Currently if fido raises a fido.exceptions.HttpTimeoutError while performing a request, the original error message will be replaced by the code in FidoFutureAdapter. This can lead to the wrong timeout value being reported in the error message.
There are two cases that can happen.
Crochet EventualResult does not receive a result within the specified wait timeout, throws a crochet.TimeoutError. In this case the future adapter should wrap the exception with fido.exceptions.HttpTimeoutError. This is the existing functionality.
Request fails with fido.exceptions.HttpTimeoutError. In this case the future adapter should reraise the original exception. Since fido.exceptions.HttpTimeoutError is a subclass of crochet.TimeoutError we need to explicitly exclude this from case 1.
Coverage increased (+0.02%) to 96.709% when pulling 083364460f17ea9594e4565b92fdabfb04d554b8 on ngaya-ll:timeout-errors into a708f4e7adde1f744f59169ae3dd7f8eaade2706 on Yelp:master.
Currently if fido raises a
fido.exceptions.HttpTimeoutError
while performing a request, the original error message will be replaced by the code inFidoFutureAdapter
. This can lead to the wrong timeout value being reported in the error message.There are two cases that can happen.
Crochet
EventualResult
does not receive a result within the specified wait timeout, throws acrochet.TimeoutError
. In this case the future adapter should wrap the exception withfido.exceptions.HttpTimeoutError
. This is the existing functionality.Request fails with
fido.exceptions.HttpTimeoutError
. In this case the future adapter should reraise the original exception. Sincefido.exceptions.HttpTimeoutError
is a subclass ofcrochet.TimeoutError
we need to explicitly exclude this from case 1.