-
Notifications
You must be signed in to change notification settings - Fork 763
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
feat: add configurable read_delay_ms #1054
Conversation
I just ran this code against our setup locally on a 2019 MacBook Pro (2,6 GHz 6-Core Intel Core i7) with With However, as the run makes a total of 1837 API requests, it could only run 2 times per hour, while the execution speed without a delay would allow for more than 6 full runs per hour. Especially when making/planning for a lot of changes repeatedly, setting a backoff therefore is preferable to me. |
This seems reasonable to me, and is a fun extension of the earlier work on write delays. I've added it to a milestone for future release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, thank you!
@kfcampbell Do I need to do anything else on this or did you just push it to get 4.21 out of the door? |
@morremeyer the second option, sorry! I'm shooting to release this on Friday this week. |
@kfcampbell No worries, just wanted to make sure I didn’t forget anything. Thank you! |
Nice feature: Perhaps another way to make it a default is to add a requests/hour configuration and set this dynamically based on it (e.g. 5000 for PAT and 15000 for App). |
This adds a configurable delay to all non-write API operations.
I set the default to be
0
so that this is a non-breaking minor version bump.Rationale
For modules using this provider, it is fairly easy to hit the rate limit for a token/user on state refresh already (see e.g. #998).
This PR will allow users to configure a backoff that will result in slower, but successful runs.
Default value considerations
A better default value that we could aim to incorporate in the next major release would be 720ms: Possibly, the most common scenario is the use with a PAT that has 5000 requests per hour. With an hour having 3600 seconds, that leads to 720ms delay between requests to reach that rate limit with read requests only.
As we pause for 1s between writes anyway, 720 milliseconds would therefore be guaranteed to not hit the rate limit if the account is not used for anything else.