github / safe-settings

ISC License
599 stars 146 forks source link

Rate limit issues #559

Open bheemvennapureddy opened 10 months ago

bheemvennapureddy commented 10 months ago

Hitting rate limits with Cron running every min

Screenshot 2023-11-17 at 10 24 13 PM
bheemvennapureddy commented 10 months ago
Screenshot 2023-11-17 at 10 30 30 PM
svg153 commented 10 months ago

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 commented 10 months ago

@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 commented 7 months ago

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 commented 6 months ago

We hardly have like 300 repos at most

bheemvennapureddy commented 6 months ago

@decyjphr any insights ?

roryscarson commented 6 months ago

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.