feat: Exponential backoff factor for HTTP request retries

[hr98w]

What was wrong?

Related to Issue #3210

How was it fixed?

Make the backoff_factor for the ExceptionRetryConfiguration class work as an actual exponential "backoff factor" And Update the doc.

Reuse backoff_factor as the initial back off time

Introduce a new field exponential_factor

Todo:

• Clean up commit history
• Add or update documentation related to these changes
• Add entry to the release notes

Cute Animal Picture

[hr98w]

@fselmo as per this issue #3210
I was considering add a new field initial_backoff_time and re-use backoff_factor as the exponential factor initially. But this will affect existing usage of field backoff_factor and might cause backward compatibility issue. Please help review the PR and share your thoughts.

[fselmo]

Hey @hr98w. Thanks for getting this started. I'm not sure that we need to add yet another configuration option here. If we make the sleep time itself exponential, the backoff factor can apply directly to that. Something like:

for i in range(self.exception_retry_configuration.retries):
    try:
        return make_post_request(
            self.endpoint_uri, request_data, **self.get_request_kwargs()
        )
    except tuple(self.exception_retry_configuration.errors) as e:
        if i < self.exception_retry_configuration.retries - 1:
            time.sleep(
                # the `backoff_factor` works as a factor on the inherent
               # exponential setup of 2**i
                self.exception_retry_configuration.backoff_factor * 2**i
            )
            continue
        else:
            raise e
return None

Thoughts on that?

[hr98w]

@fselmo sure, this also works.

I introduced a new variable to let users determine the exponential factor. Keeping that factor as 1 means no exponenial backoff. We can keep it simple here, will follow your advice.

[fselmo]

I introduced a new variable to let users determine the exponential factor. Keeping that factor as 1 means no exponenial backoff. We can keep it simple here, will follow your advice.

I hear you. That would allow for more configuration for sure. Exponential is pretty standard and keeping that factor low still allows for pretty quick succession if desired. If you're good with my simpler approach then let's go for it 👍🏼

[fselmo]

We should maybe decrease the default value here to 0.125? That would yield .125 -> .25 -> .5 -> 1 -> 2. That feels pretty good for JSON-RPC calls. Thoughts there?

[hr98w]

Starting from 0.5 seems too large for me. But i'm not sure for JSON-RPC calls, any latency stats you can share?

[hr98w]

@fselmo Updated the PR, please help review

[fselmo]

With a few tweaks to the wording this LGTM. I gave some suggestions to the wording. The important thing here is clarity and I don't think we need to be super technical in the documentation description since we can conceptually describe the doubling strategy. The technical details can be sniffed out by a curious user if they'd like to see the implementation. I'd love your thoughts on it though. Thanks again for getting the ball rolling on this... this is one of the final pieces for getting v7 wrapped up 👍🏼

[hr98w]

@fselmo Thanks for your comment! Got your point to make it easy to understand. Resolved them.

[fselmo]

Thanks again 👍🏼