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

Rate limit issues #559

Open
bheemvennapureddy opened this issue Nov 18, 2023 · 7 comments
Open

Rate limit issues #559

bheemvennapureddy opened this issue Nov 18, 2023 · 7 comments
Labels
bug Something isn't working

Comments

@bheemvennapureddy
Copy link
Contributor

bheemvennapureddy commented Nov 18, 2023

Hitting rate limits with Cron running every min

Screenshot 2023-11-17 at 10 24 13 PM
@bheemvennapureddy bheemvennapureddy added the bug Something isn't working label Nov 18, 2023
@bheemvennapureddy
Copy link
Contributor Author

Screenshot 2023-11-17 at 10 30 30 PM

@svg153
Copy link
Contributor

svg153 commented Nov 21, 2023

The CRON is not designed to be launched every minute. It is a reconciliation system that was put in place to consolidate the state in the safe-settings files and the real state of github, with the aim of not having a rate limit with so many requests to the API. Why do you have Chrome every minute? What are you trying to solve?
cc: @decyjphr

@bheemvennapureddy
Copy link
Contributor Author

@svg153 i assume CRON is to gurantee that all the policies are correctly applied and some one trying to overwrite any of these policies like say adding labels manually should be overwritten by Safesettings no ? same goes to any status checks or branch protection rules cc: @decyjphr

i feel there is a bug in the system which is causing the rate limit issues - some stats below what i received from github

Screenshot 2023-11-21 at 7 46 53 PM

Top-url-CuroFinTechCorp.csv
Top_route-CuroFinTechCorp.csv

@martinm82
Copy link
Contributor

What is the number of repositories within your organization? We have the same issue with rate limits but in our case the issue is that safe-settings just does not scale with large orgs (in our case >10k repos). We needed to change the cycle of the cron to be executed every 4-6 hours as otherwise we would hit immediately the rate limit.

Some changes, like branch protection rules are almost immediately changed back to the ones defined by the safe-settings configurations. This is achieved by webhook events (see index.js for the events that trigger an update of the repo settings).

To solve the rate limit issue, I started to change a bit the application and tried to split it into two, one for the cron part and the other for the webhook based events, so that it is always guaranteed that the webhook events will be properly executed by the safe-settings application by using its dedicated GitHub App with its own rate limit.

But there is a problem with consistency that makes it impossible without modifications in the code to have two safe-settings app running in parallel, as somehow data is cached and settings are overwritten either by the cron or webhook container.

@bheemvennapureddy
Copy link
Contributor Author

We hardly have like 300 repos at most

@bheemvennapureddy
Copy link
Contributor Author

@decyjphr any insights ?

@roryscarson
Copy link

Manual modifications should trigger a webhook event that will then trigger safe-settings to update settings of that type(ie Repository events will trigger repository setting sync, Branch protection will trigger branch protection, etc).

We have ~500 live, 1500 total repos hitting ratelimits trying to sync every 15 minutes. Changed the sync to ever 4 hours and it worked. FYI safe-settings still checks archived repos which could slow down your check a lot if you aren't deleting or moving old repos and are instead just archiving them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants