GitHub API-Ratelimit überschritten: was dies bedeutet und wie man damit umgeht

GitHub beschränkt die Anzahl der REST-API-Anforderungen, die Ihre App senden kann. Wenn Sie einen Grenzwert überschreiten, weist GitHub Ihre Anforderungen mit dem Status 403 oder 429 ab, bis der Grenzwert zurückgesetzt wird oder die Wartezeit abgelaufen ist. GitHub hat 2 Arten von Grenzwerten: eine primäre Grenze für Anfragen pro Stunde und sekundäre Grenzwerte, die vor Lastspitzen schützen. Wenn Ihre App weiterhin Anforderungen sendet, während sie einer Mengenbeschränkung unterliegt, kann GitHub Ihre Integration möglicherweise verbieten. Weitere Informationen finden Sie unter Begrenzungen für die REST-API.

Wie die GitHub-Ratenbeschränkungen aussehen

Limit Value Wenn Sie es durchgehen
Primär, nicht authentifiziert 60 Anfragen pro Stunde, pro IP-Adresse 403 oder 429, und x-ratelimit-remaining ist 0
Primäres, persönliches Zugriffstoken 5.000 Anforderungen pro Stunde Wie oben
Primär, GITHUB_TOKEN in GitHub Actions 1.000 Anfragen pro Stunde, pro Repository Wie oben
Secondary Beispielsweise sind nicht mehr als 100 gleichzeitige Anfragen, 900 Punkte pro Minute für REST-Endpunkte und etwa 80 Anfragen zur Inhaltsgenerierung pro Minute zulässig. 403 oder 429 mit einer Fehlermeldung. retry-after kann vorhanden sein.

GitHub kann sekundäre Grenzwerte ohne Vorankündigung ändern, und es gibt keine Möglichkeit, zu überprüfen, wie nahe Sie an diese Grenzwerte herankommen.

Jede Antwort enthält Kopfzeilen, die Ihnen mitteilen, wo Sie sich am primären Grenzwert befinden:

Header Was es Ihnen sagt
x-ratelimit-limit Die maximale Anzahl von Anforderungen, die pro Stunde gesendet werden können
x-ratelimit-remaining Die Anzahl der Anforderungen, die sich noch im aktuellen Fenster befinden
x-ratelimit-used Die Anzahl der Anforderungen, die Sie im aktuellen Fenster gesendet haben
x-ratelimit-reset Wenn das Fenster zurückgesetzt wird, in UTC-Epochen sekunden
x-ratelimit-resource Auf welchen Grenzwert die Anforderung angerechnet wurde

Umgang mit einer GitHub-Ratenbegrenzung

  1. Unterscheiden Sie ein Ratelimit von einem Berechtigungsfehler. GitHub gibt auch 403 zurück, wenn Ihrem Token die Berechtigung fehlt. Wenn die Antwort keine retry-after hat, x-ratelimit-remaining nicht 0 ist und die Nachricht keine Ratenbegrenzung erwähnt, handelt es sich um ein Berechtigungsproblem. Versuchen Sie es nicht erneut.
  2. Folgen Sie retry-after zuerst. Wenn die Kopfzeile vorhanden ist, warten Sie entsprechend viele Sekunden.
  3. Warten Sie andernfalls auf den Reset. Wenn x-ratelimit-remaining0 ist, versuchen Sie es erst nach der Zeit in x-ratelimit-reset.
  4. Warten Sie andernfalls mindestens 1 Minute. Für einen sekundären Grenzwert ohne einen der beiden Header fordert GitHub Sie auf, mindestens 1 Minute zu warten und nach jedem fehlgeschlagenen Wiederholungsvorgang länger zu warten. Beenden Sie den Vorgang nach einer festgelegten Anzahl von Wiederholungsversuchen, und melden Sie einen Fehler.
  5. Reduzieren Sie das Tempo, bevor Ihnen das Kontingent ausgeht. Verwenden Sie x-ratelimit-remaining und x-ratelimit-reset, um Ihre Anforderungen zu steuern. Bauen Sie keine Logik auf einer exakten verbleibenden Anzahl auf, da GitHub Grenzwerte ändern kann. Die x-ratelimit-* Header sind die maßgebliche Quelle, nicht der GET /rate_limit Endpunkt.
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;
}

Der Aufrufer versucht es erneut, wenn die Funktion eine Zahl zurückgibt, und beendet den Vorgang nach einigen Versuchen.

So testen Sie, ob Ihre App mit GitHub-Ratenbegrenzungen umgehen kann

Beim Entwickeln wird selten ein GitHub Ratelimit erreicht. Sie senden ein paar Anfragen, und 5.000 pro Stunde fühlt sich endlos an. Die Art und Weise, wie Sie die Behandlung von Ratenbeschränkungen testen, entscheidet also, ob Sie die Fehler finden, bevor Ihre Benutzer dies tun.

Approach Was Sie finden Was Ihnen fehlt
Auf die Produktion warten Echte Fehler Alles, bis ein Benutzer darauf klickt
Simulieren Sie die API in Ihren Tests oder lassen Sie Ihren Codierungs-Agent die Simulation schreiben. Ob die Wiederholungsverzweigung ausgeführt wird GitHubs echte Header und Fehlertexte und die Wiederholungsrichtlinie Ihres SDKs. Ihre App benötigt außerdem einen reinen Testschalter, um den Mock zu erreichen.
Rufen Sie die echte API auf, bis sie Sie einschränkt. Tatsächliches Verhalten Es erfordert bis zu 5.000 Anforderungen, Sie können keinen sekundären Grenzwert bei Bedarf auslösen, und Sie riskieren ein Verbot Ihrer Integration.
Fangen Sie den tatsächlichen Datenverkehr Ihrer App ab und geben Sie bei Bedarf Antworten mit Ratenbegrenzungen zurück. Echte URLs, Ihr reales SDK und Wiederholungsrichtlinie sowie GitHubs eigene Header und Fehlerformat An Ihrer App ändert sich nichts, daher wird Ihr Code nicht isoliert getestet. Verwenden Sie dafür Ihre Komponententests.

Testen Sie es in Ihrer App

Dev Proxy fängt die Anfragen Ihrer App an api.github.com ab und gibt GitHub-Stil-Rate-Limit-Antworten zurück, während Ihre App die tatsächlichen URLs aufruft. Das github-rate-limiting Preset zählt Ihre Anfragen auf ein Limit von 60 pro Stunde an, sendet die x-ratelimit-* Header und gibt ein 429 mit API rate limit exceeded zurück, wenn Ihr Limit ausgeschöpft ist. Bis dahin werden Ihre Anfragen an GitHub gesendet und auch auf Ihr tatsächliches Limit angerechnet.

Laden Sie die Voreinstellung herunter, und starten Sie Dev Proxy damit:

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

Um sekundäre Grenzwerte zu testen, starten Sie stattdessen Dev Proxy mit devproxyrc-secondary.json aus demselben Ordner. Es wird zufällig ein sekundäres Rate-Limit 429 mit einer retry-after Kopfzeile zurückgegeben.

Führen Sie dann Ihre App wie gewohnt aus, und beobachten Sie, was sie tut. Informationen zum Installieren von Dev Proxy finden Sie unter Einrichten von Dev Proxy.

Nächste Schritte

Testen, wie Ihre App GitHub API-Ratenbeschränkungen behandelt

Siehe auch

  • Zuletzt aktualisiert um