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, wird GitHub Ihre Anfragen mit dem Status 403 oder 429 abweisen, bis das Limit 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 Anfragen sendet, während sie einem Rate-Limit unterliegt, kann GitHub Ihre Integration möglicherweise verbieten. Weitere Informationen finden Sie unter Ratenbegrenzungen für die REST-API.

Wie die GitHub-Ratenbeschränkungen aussehen

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:

Umgang mit einem GitHub-Ratenlimit

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 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 Anfragen 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 erneut, wenn die Funktion eine Zahl zurückgibt, und hört nach einigen Versuchen auf.

So testen Sie, ob Ihre App mit GitHub-Ratenlimits 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.

Probieren Sie sie mit Ihrer App aus

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

Siehe auch

• 429 Zu viele Anfragen: Was dies bedeutet und wie sie behandelt werden
• Der Retry-After-Header: wie lange gewartet werden soll, bevor Sie es erneut versuchen
• Was ist die Zinsbegrenzung?
• Umgang mit der Ratenbegrenzung
• API-Antworten zur Ratenbegrenzung simulieren
• RateLimitingPlugin