-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems using Configurable Retry Policy #21
Comments
Additional observations:
|
opsgenie-python-sdk/opsgenie_sdk/api_client.py Lines 84 to 86 in f2a2103
|
This is needed because the retry logic in SDK doesn't work properly :-( (see opsgenie#21)
This is needed because the retry logic in SDK doesn't work properly :-( (see opsgenie#21)
Hi, thanks a bunch for pointing out all of this and sorry for the late response. I have changed the explanations of the The bug which was preventing the disablement of retrying will be fixed, by implementing a custom callback function for deciding whether the retry should stop or not, when #29 is released. I will remove the unused I agree that the And I am looking into why the metrics are not being published when |
Coming back to metrics' publishing, http metrics are published only after an http request is completed. However, to make debugging easier, I have added a change to publish sdk metrics whenever an exception is thrown while attempting to call the api in b382348 |
I'm closing the ticket now. Thanks for the collaborative work guys. If we need an another improvement later, let's create a new issue then. |
Looking at the documentation on Configurable Retry Policy Support:
retry_count
is documented as "Number of times a request is tried upon encountering a specific response code, such as 429." however I don't think the implementation respects this -- I believe it will make a total ofretry_count
attempts across any error type.retry_delay
andretry_max_delay
documentation does not make it clear that these parameters control the full jitter algorithm. Also, they probably don't need to be integers.retry_max_delay
is documented as "The upper limit for the amount of time, in seconds, for which the retries will be attempted for." which is not respected, but would be useful to have. (i.e. I think you should addtenacity.stop_after_delay(configuration.retry_max_delay)
to theRetrying(stop=...)
argument, so that there is a way to limit the total amount of time spent retrying.)Separately, it doesn't look like metrics are getting published during retries because
opsgenie_sdk.rest.RESTClientObject.request()
does not publish HTTP Metrics in the scenario wherepool_manager.request()
raises an exception. This is making it harder for me to debug what is going on.The text was updated successfully, but these errors were encountered: