GitHub API: překročen limit počtu požadavků: co to znamená a jak to řešit

GitHub omezuje počet požadavků rozhraní REST API, které může vaše aplikace odesílat. Když překročíte limit, GitHub vaše požadavky odmítne se stavem 403 nebo 429, dokud se limit neobnoví nebo neuplyne čekací doba. GitHub má 2 druhy omezení: primární limit požadavků za hodinu a sekundární limity, které chrání před nárazovými špičkami. Pokud vaše aplikace bude posílat žádosti v době, kdy narazí na omezení počtu požadavků, GitHub může vaši integraci zakázat. Další informace najdete v tématu Omezení rychlosti pro rozhraní REST API.

Jak vypadají limity počtu požadavků GitHubu

Limit Value Když si to projdete
Primární, neověřený 60 požadavků za hodinu na IP adresu 403 nebo 429, a x-ratelimit-remaining je 0
Primární, osobní přístupový token 5 000 požadavků za hodinu Stejné jako výše uvedené
Primární v GITHUB_TOKEN GitHub Actions 1 000 požadavků za hodinu na úložiště Stejné jako výše uvedené
Secondary Například maximálně 100 souběžných požadavků, 900 bodů za minutu pro koncové body REST a přibližně 80 požadavků generující obsah za minutu 403 nebo 429 s chybovou zprávou. retry-after může být přítomna.

GitHub může měnit sekundární limity bez předchozího upozornění a neexistuje způsob, jak zkontrolovat, jak blízko k nim jste.

Každá odpověď obsahuje hlavičky, které vám řeknou, kde stojíte na primárním limitu:

Header Co vám to říká
x-ratelimit-limit Maximální počet požadavků, které můžete odeslat za hodinu
x-ratelimit-remaining Kolik požadavků zbývá v aktuálním okně
x-ratelimit-used Kolik požadavků jste odeslali v aktuálním okně
x-ratelimit-reset Po resetování okna v epochách UTC
x-ratelimit-resource Do kterého limitu se žádost počítá

Zpracování limitu rychlosti GitHub

  1. Oddělte limit požadavků od chyby oprávnění. GitHub se 403 vrátí také v případech, kdy token nemá přístup. Pokud odpověď nemá retry-after, x-ratelimit-remaining není 0 a zpráva nezmiňuje limit počtu požadavků, jedná se o problém s oprávněními. Nezkoušejte to znovu.
  2. Nejprve postupujte podle retry-after. Pokud je záhlaví k dispozici, počkejte na tento počet sekund.
  3. V opačném případě počkejte na resetování. Pokud x-ratelimit-remaining je 0, nezkoušejte to znovu, dokud nenastane čas v x-ratelimit-reset.
  4. Jinak počkejte aspoň 1 minutu. V případě sekundárního limitu bez záhlaví vás GitHub požádá, abyste čekali aspoň 1 minutu a po každém neúspěšném opakování čekali déle. Zastavte po nastaveném počtu opakování a vyvolejte chybu.
  5. Zpomalte, než vám dojde limit. Pomocí x-ratelimit-remaining a x-ratelimit-reset můžete regulovat své požadavky. Nestavte logiku na přesném zbývajícím počtu, protože GitHub může změnit limity. Hlavičky x-ratelimit-* jsou zdrojem pravdy, nikoli GET /rate_limit endpointu.
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;
}

Volající provede opakovaný pokus, když funkce vrátí číslo, a zastaví se po několika pokusech.

Jak otestovat, že aplikace zpracovává omezení počtu požadavků GitHubu

Při vývoji zřídka dosáhnete limitu počtu požadavků GitHubu. Posíláte několik požadavků a limit 5 000 za hodinu se zdá být neomezený. Způsob, jakým testujete zpracování omezení četnosti, tedy rozhoduje o tom, zda chyby zjistíte dříve, než je odhalí vaši uživatelé.

Approach Co najdete Co vám chybí
Počkejte na produkční prostředí Skutečná selhání Všechno, dokud na to uživatel neklikne
Mockujte API ve svých testech nebo nechte svého programovacího agenta vytvořit mock Jestli se vaše větev opakování pokusu spustí Skutečné hlavičky a texty chyb z GitHubu a zásady opakování vaší sady SDK. Vaše aplikace také potřebuje testovací přepínač pro přístup k mocku.
Volejte skutečné rozhraní API, dokud vás nezačne omezovat Skutečné chování Vyžaduje to až 5 000 požadavků, nemůžete aktivovat sekundární limit na vyžádání a riskujete zákaz integrace.
Zachyťte skutečný provoz vaší aplikace a vracejte odpovědi při omezení rychlosti na vyžádání Skutečné adresy URL, skutečná sada SDK a zásady opakování a vlastní hlavičky a formát chyb GitHubu Ve vaší aplikaci se nic nemění, takže netestuje váš kód izolovaně. Na to si nechte unit testy.

Vyzkoušejte si ji ve své aplikaci

Dev Proxy zachytává požadavky vaší aplikace na api.github.com a vrací odpovědi s omezením rychlosti ve stylu GitHubu, zatímco aplikace bude dál volat skutečné adresy URL. Přednastavení github-rate-limiting počítá vaše požadavky do limitu 60 za hodinu, odešle hlavičky x-ratelimit-* a vrátí 429 s API rate limit exceeded, když limit vyčerpáte. Do té doby vaše požadavky směřují na GitHub a započítávají se i do vašeho skutečného limitu.

Stáhněte si předvolbu a spusťte dev Proxy:

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

Pokud chcete otestovat sekundární limity, spusťte místo toho Dev Proxy devproxyrc-secondary.json ze stejné složky. Náhodně vrátí sekundární omezení počtu požadavků 429 se záhlavím retry-after.

Pak aplikaci spusťte obvyklým způsobem a sledujte, co to dělá. Informace o instalaci Dev Proxy najdete v tématu Nastavení Dev Proxy.

Další kroky

Testování, jak vaše aplikace zpracovává omezení počtu volání rozhraní API GitHub

Viz také

  • Poslední aktualizace v