GitHub limite di frequenza API superato: cosa significa e come gestirlo

GitHub limita il numero di richieste api REST che l'app può inviare. Quando si supera un limite, GitHub respinge le richieste con stato 403 o 429 fino a quando il limite non viene reimpostato o il tempo di attesa passa. GitHub ha 2 tipi di limiti: un limite primario per le richieste all'ora e limiti secondari che proteggono da picchi. Se l'app continua a inviare richieste mentre è soggetta a limitazioni di frequenza, GitHub potrebbe bloccare la tua integrazione. Per altre informazioni, vedere Limiti di frequenza per l'API REST.

Come si presentano i limiti di velocità di GitHub

Limit Value Quando lo esamini
Primario, non autenticato 60 richieste all'ora, per indirizzo IP 403 o 429, e x-ratelimit-remaining è 0
Token di accesso primario, personale 5.000 richieste all'ora Vedere quanto riportato in precedenza
Principale, GITHUB_TOKEN in GitHub Actions 1.000 richieste all'ora, per repository Vedere quanto riportato in precedenza
Secondary Ad esempio, non più di 100 richieste simultanee, 900 punti al minuto per gli endpoint REST e circa 80 richieste di generazione di contenuto al minuto 403 o 429 con un messaggio di errore. retry-after potrebbe essere presente.

GitHub può modificare i limiti secondari senza preavviso e non c'è modo di verificare quanto si è vicini a tali limiti.

Ogni risposta include intestazioni che indicano a che punto sei rispetto al limite primario:

Header Cosa ti dice
x-ratelimit-limit Il numero massimo di richieste che è possibile inviare all'ora
x-ratelimit-remaining Quante richieste ti restano nella finestra corrente
x-ratelimit-used Quante richieste hai inviato nella finestra corrente
x-ratelimit-reset Quando la finestra viene reimpostata, in secondi dell'epoca UTC
x-ratelimit-resource A quale limite viene conteggiata la richiesta

Come gestire un limite di richieste di GitHub

  1. Distingui un limite di frequenza da un errore di autorizzazione. GitHub restituisce 403 anche quando il token non dispone delle autorizzazioni necessarie. Se la risposta non ha retry-after, x-ratelimit-remaining non è 0 e il messaggio non menziona un limite di frequenza, si tratta di un problema di autorizzazione. Non riprovarci.
  2. Segui retry-after prima. Se l'intestazione è presente, attendere quel numero di secondi.
  3. In caso contrario, attendere il ripristino. Se x-ratelimit-remaining è 0, non riprovare fino all'ora indicata in x-ratelimit-reset.
  4. In caso contrario, attendere almeno 1 minuto. Per un limite secondario senza nessuna delle due intestazioni, GitHub chiede di attendere almeno 1 minuto e di attendere più tempo dopo ogni tentativo non riuscito. Arrestare dopo un numero prestabilito di tentativi e generare un errore.
  5. Rallenta prima di esaurire le risorse. Usare x-ratelimit-remaining e x-ratelimit-reset per gestire le richieste. Non creare logica intorno a un conteggio esatto rimanente, perché GitHub può modificare i limiti. Gli x-ratelimit-* header sono la fonte attendibile, non l'endpoint GET /rate_limit.
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;
}

Il chiamante ritenta quando la funzione restituisce un numero e si arresta dopo alcuni tentativi.

Come testare che l'app gestisca i limiti di frequenza di GitHub

Raramente si raggiunge un limite di frequenza GitHub durante lo sviluppo. Si inviano alcune richieste e 5.000 all'ora si sentono infinite. Quindi, il modo in cui si testa la gestione dei limiti di frequenza decide se si trovano i bug prima che gli utenti eseseguono l'operazione.

Avvicinarsi Cosa trovi Quello che ti manca
Attendere l'ambiente di produzione Errori reali Tutto, fino a quando un utente non lo preme
Simula l'API nei test oppure lascia che l'agente di codifica scriva il mock Se il ramo di ripetizione dei tentativi viene eseguito Le intestazioni reali di GitHub, i corpi degli errori e i criteri di ripetizione dei tentativi dell'SDK. L'app richiede anche uno switch solo test per raggiungere il mock.
Chiamare l'API reale fino a quando non ti limita Comportamento reale Richiede fino a 5.000 richieste, non è possibile attivare un limite secondario su richiesta e rischi che la tua integrazione venga bloccata
Intercetta il traffico reale della tua app e restituisci risposte di limite di frequenza su richiesta URL reali, il tuo vero SDK e la politica di ritentativo, nonché le intestazioni e il formato di errore propri di GitHub Niente nella tua app cambia, quindi non testa il codice in isolamento. Conserva gli unit test per quello.

Provalo nella tua app

Dev Proxy intercetta le richieste dell'app a api.github.com e restituisce risposte di limite di frequenza GitHub stile, mentre l'app continua a chiamare gli URL reali. Il github-rate-limiting set di impostazioni conteggia le tue richieste ai fini di un limite di 60 all'ora, invia le intestazioni x-ratelimit-* e restituisce un 429 con API rate limit exceeded quando esaurisci il limite. Fino ad allora, le richieste vengono inviate a GitHub e vengono conteggiate anche ai fini del limite reale.

Scaricare il set di impostazioni e avviare Dev Proxy con esso:

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

Per testare i limiti secondari, avviare Dev Proxy con devproxyrc-secondary.json dalla stessa cartella. Restituisce in modo casuale un limite 429 di frequenza secondario con un'intestazione retry-after .

Eseguire quindi l'app come di consueto e osservare cosa fa. Per installare Dev Proxy, vedere Configurare Dev Proxy.

Passaggi successivi

Testare il modo in cui l'app gestisce i limiti di frequenza dell'API di GitHub

Vedere anche

  • Last updated on