GitHub API-frequentielimiet overschreden: wat betekent dit en hoe u deze kunt afhandelen

GitHub beperkt het aantal REST API-aanvragen dat uw app kan verzenden. Wanneer u een limiet overschrijdt, wijst GitHub uw verzoeken af met een 403- of 429-status totdat de limiet opnieuw wordt ingesteld of de wachttijd is verstreken. GitHub heeft twee soorten limieten: een primaire limiet voor aanvragen per uur en secundaire limieten die beschermen tegen bursts. Als uw app aanvragen blijft verzenden terwijl er een rate limit van kracht is, kan GitHub uw integratie blokkeren. Zie Frequentielimieten voor de REST API voor meer informatie.

Hoe zien de frequentielimieten van GitHub eruit

Limit Value Wanneer u het doorneemt
Primair, niet-aangemeld 60 aanvragen per uur, per IP-adres 403 of 429, en x-ratelimit-remaining is 0
Primair, persoonlijk toegangstoken 5000 aanvragen per uur Hetzelfde als hierboven
Primary, GITHUB_TOKEN in GitHub Actions 1000 aanvragen per uur, per repository Hetzelfde als hierboven
Secundaire Bijvoorbeeld niet meer dan 100 gelijktijdige aanvragen, 900 punten per minuut voor REST-eindpunten en ongeveer 80 aanvragen voor het genereren van inhoud per minuut 403 of 429 met een foutbericht. retry-after kan aanwezig zijn.

GitHub kan zonder kennisgeving secundaire limieten wijzigen en er is geen manier om te controleren hoe dicht u bij deze limieten bent.

Elk antwoord bevat headers die u vertellen waar u zich bevindt op de primaire limiet:

Header Wat het u vertelt
x-ratelimit-limit Het maximum aantal aanvragen dat u per uur kunt verzenden
x-ratelimit-remaining Hoeveel verzoeken u nog hebt in het huidige venster
x-ratelimit-used Hoeveel aanvragen hebt u in het huidige venster verzonden
x-ratelimit-reset Wanneer het venster opnieuw wordt ingesteld, in UTC-epochseconden
x-ratelimit-resource Tegen welke limiet de aanvraag wordt meegeteld

Omgaan met een GitHub-ratelimiet

  1. Maak onderscheid tussen een frequentielimiet en een machtigingsfout. GitHub retourneert 403 ook wanneer uw token onvoldoende toegangsmachtigingen heeft. Als het antwoord geen retry-after heeft, x-ratelimit-remaining niet 0 is, en het bericht geen frequentielimiet vermeldt, is dit een autorisatieprobleem. Probeer het niet opnieuw.
  2. Volg retry-after eerst. Als de koptekst aanwezig is, wacht u dat aantal seconden.
  3. Wacht anders op de reset. Als x-ratelimit-remaining0 is, probeer het niet opnieuw vóór de tijd in x-ratelimit-reset.
  4. Wacht anders minstens 1 minuut. Voor een secundaire limiet zonder een van beide headers vraagt GitHub u om ten minste 1 minuut te wachten en na elke mislukte nieuwe poging langer te wachten. Stop na een bepaald aantal herhalingen en geef een fout.
  5. Vertraag voordat je limiet opraakt. Gebruik x-ratelimit-remaining en x-ratelimit-reset om het tempo van uw aanvragen aan te passen. Bouw geen logica rond een exacte resterende telling, omdat GitHub limieten kan wijzigen. De x-ratelimit-* headers zijn de bron van waarheid, niet het GET /rate_limit eindpunt.
async function githubWaitMs(response, attempt) {
  if (response.status !== 403 && response.status !== 429) {
    return null;
  }
  const retryAfter = response.headers.get('retry-after');
  if (retryAfter) {
    return Number(retryAfter) * 1000;
  }
  if (response.headers.get('x-ratelimit-remaining') === '0') {
    const resetMs = Number(response.headers.get('x-ratelimit-reset')) * 1000;
    return Math.max(resetMs - Date.now(), 0);
  }
  const { message = '' } = await response.clone().json().catch(() => ({}));
  if (response.status === 429 || /rate limit/i.test(message)) {
    return 60_000 * 2 ** attempt;
  }
  // A 403 without rate limit signals is a permission problem: don't retry
  return null;
}

De aanroeper probeert opnieuw wanneer de functie een getal retourneert en stopt na een paar pogingen.

Testen of uw app GitHub-ratelimieten verwerkt

U hebt zelden een GitHub-ratelimiet bereikt tijdens het ontwikkelen. U verzendt een paar aanvragen en 5.000 per uur voelt eindeloos. De manier waarop u de afhandeling van rate limits test, bepaalt dus of u de bugs vindt voordat uw gebruikers dat doen.

Approach Wat u vindt Wat u mist
Wachten op de productie Werkelijke storingen Alles, totdat een gebruiker erop klikt
Mock de API in je tests, of laat je coding agent de mock schrijven Of uw retry-tak wordt uitgevoerd de echte headers en foutteksten van GitHub en het retrybeleid van uw SDK. Uw app heeft ook een schakelaar nodig die alleen voor testdoeleinden is om de mock te bereiken.
Roep de echte API aan totdat u wordt beperkt Werkelijk gedrag Er zijn maximaal 5.000 aanvragen nodig, u kunt geen secundaire limiet naar wens activeren en u loopt het risico op een verbod op uw integratie
Het werkelijke verkeer van uw app onderscheppen en reacties op retourfrequentielimieten op aanvraag Echte URL's, uw echte SDK en retrybeleid, en de eigen headers en foutindeling van GitHub Er verandert niets in uw app, dus test het uw code niet geïsoleerd. Bewaar je unittests daarvoor.

Probeer het uit in je app

Dev Proxy onderschept de aanvragen van uw app naar api.github.com en retourneert GitHub-achtige rate-limitreacties, terwijl uw app de echte URL's blijft aanroepen. De github-rate-limiting voorinstelling telt uw aanvragen mee voor een limiet van 60 per uur, verzendt de x-ratelimit-* headers en retourneert een 429 met API rate limit exceeded wanneer u uw limiet bereikt. Tot die tijd gaan uw aanvragen ook naar GitHub en tellen ze mee voor uw werkelijke limiet.

Download de voorinstelling en start de Dev Proxy ermee:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Als u secundaire limieten wilt testen, start u in plaats daarvan Dev Proxy vanuit dezelfde map met devproxyrc-secondary.json. Er wordt willekeurig een secundaire ratelimiet 429 met een retry-after header geretourneerd.

Voer vervolgens uw app zoals gebruikelijk uit en bekijk wat deze doet. Zie Dev Proxy instellen om Dev Proxy te installeren.

Volgende stappen 

Test hoe uw app omgaat met GitHub API-frequentielimieten

Zie ook

  • Laatst bijgewerkt om