I think I was under the impression from looking at this line that the backoff decorator on this method was there to handle backoff-able HTTP status codes (

429

etc.). I’ve noticed that a few of our taps that leverage this stream class are getting rate limited and immediately throwing a

RuntimeError

instead of retrying at all. Upon further inspection of the method, it seems like the only path to the backoff getting triggered is via

Timeout

,

ConnectionError

, and

TooManyRedirects

exceptions, since the method isn’t explicitly raising

HTTPError

anywhere based on the status code of the response.

am I missing an implementation detail here? Or is this method more of an abstract-style method that is meant to be overridden if you want to handle retryable errors like rate limiting

Oh wait - I think I just initially misread the

giveup

logic. It looks like it’s just giving up on anything client end. That makes more sense

so then it seems pretty clear that this method is intentionally not trying to handle things like rate limiting