Skip to content
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

Merged
merged 1 commit into from
Mar 18, 2022

Conversation

morremeyer
Copy link
Contributor

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.

@morremeyer
Copy link
Contributor Author

I just ran this code against our setup locally on a 2019 MacBook Pro (2,6 GHz 6-Core Intel Core i7) with read_delay_ms = 0, it ran for 8 minutes 39 seconds.

With read_delay_ms = 720, it ran for 21 minutes and 3 seconds.

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.

@morremeyer morremeyer marked this pull request as ready for review February 1, 2022 16:16
@kfcampbell kfcampbell added this to the v4.21.0 milestone Feb 2, 2022
@kfcampbell
Copy link
Member

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.

Copy link
Member

@kfcampbell kfcampbell left a 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 kfcampbell modified the milestones: v4.21.0, v4.22.0 Mar 11, 2022
@morremeyer
Copy link
Contributor Author

@kfcampbell Do I need to do anything else on this or did you just push it to get 4.21 out of the door?

@kfcampbell
Copy link
Member

@morremeyer the second option, sorry! I'm shooting to release this on Friday this week.

@morremeyer
Copy link
Contributor Author

@kfcampbell No worries, just wanted to make sure I didn’t forget anything. Thank you!

@kfcampbell kfcampbell merged commit da590ae into integrations:main Mar 18, 2022
@jspiro
Copy link
Contributor

jspiro commented May 11, 2022

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).

kfcampbell pushed a commit to kfcampbell/terraform-provider-github that referenced this pull request Jul 26, 2022
kazaker pushed a commit to auto1-oss/terraform-provider-github that referenced this pull request Dec 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants