GitHub API-sebességkorlát túllépése: mit jelent és hogyan kezelhető

A GitHub korlátozza, hogy az alkalmazásod hány REST API-kérést küldhet. Ha túllépsz egy korlátot, a GitHub elutasítja a kéréseidet 429 vagy 403 állapottal, amíg a korlát alaphelyzetbe nem áll, vagy a várakozási idő el nem telik. A GitHub kétféle korlátozással rendelkezik: az óránkénti kérések elsődleges korlátja, valamint a hirtelen kéréshullámok ellen védő másodlagos korlátok. Ha az alkalmazás továbbra is kéréseket küld, amíg korlátozott a sebesség, GitHub betilthatja az integrációt. További információ: A REST API sebességkorlátjai.

Hogyan néznek ki GitHub sebességkorlátai?

Limit Value Amikor átmegy rajta
Elsődleges, hitelesítés nélküli 60 kérés óránként, IP-címenként 403 vagy 429, és x-ratelimit-remaining a 0
Elsődleges, személyes hozzáférési token Óránként 5000 kérés Lásd fent
Elsődleges, GITHUB_TOKEN a GitHub Actionsben 1000 kérelem óránként, adattáranként Lásd fent
Másodlagos Például legfeljebb 100 egyidejű kérés, 900 pont/perc REST-végpont és körülbelül 80 tartalomgeneráló kérés percenként 403 vagy 429 hibaüzenettel. retry-after lehet, hogy jelen van.

GitHub értesítés nélkül módosíthatja a másodlagos korlátokat, és nem lehet ellenőrizni, hogy milyen közel van hozzájuk.

Minden válasz tartalmaz fejléceket, amelyek jelzik, hogy hol áll az elsődleges korláton:

Header Mit mond el?
x-ratelimit-limit Az óránként küldhető legtöbb kérés
x-ratelimit-remaining Hány kérés maradt az aktuális ablakban
x-ratelimit-used Az aktuális időablakban elküldött kérések száma
x-ratelimit-reset Amikor az ablak alaphelyzetbe áll, UTC korszak kezdete óta eltelt másodpercekben
x-ratelimit-resource Mely korlátba számít bele a kérés

GitHub sebességkorlát kezelése

  1. Adjon meg egy sebességkorlátot egy engedélyhiba mellett. A GitHub akkor is visszaadja a(z) 403 elemet, ha a token nem rendelkezik hozzáféréssel. Ha a válasz nem retry-after, x-ratelimit-remaining nem 0, és az üzenet nem említi a sebességkorlátot, ez engedélyproblémát jelent. Ne próbálja újra.
  2. Először kövesd retry-after. Ha a fejléc jelen van, várjon ennyi másodpercet.
  3. Ellenkező esetben várja meg az alaphelyzetbe állítást. Ha x-ratelimit-remaining0, ne próbálkozzon újra a(z) x-ratelimit-reset mezőben szereplő időpontig.
  4. Ellenkező esetben várjon legalább 1 percet. A fejléc nélküli másodlagos korlát esetén GitHub arra kéri, hogy legalább 1 percet várjon, és várjon tovább az egyes sikertelen újrapróbálkozások után. Állítsa le a megadott számú újrapróbálkozás után, és hibát jelezzen.
  5. Lassíts, mielőtt elfogy. A kérések használata x-ratelimit-remaining és x-ratelimit-reset üteme. Ne építsen logikát a pontos hátralévő értékre, mert a GitHub módosíthatja a korlátokat. A x-ratelimit-* fejlécek az igazság forrását képezik, nem pedig a GET /rate_limit végpont.
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;
}

A hívó újrapróbálkozik, ha a függvény egy számot ad vissza, és néhány kísérlet után leáll.

Annak tesztelése, hogy az alkalmazás kezeli-e a GitHub lekérési korlátait

Fejlesztés közben ritkán éred el a GitHub API-korlátját. Küldjön néhány kérést, és az óránkénti 5000 szinte végtelennek tűnik. Így a rátakorlát kezelésének tesztelése dönti el, hogy megtalálja-e a hibákat a felhasználók előtt.

Approach Mit talál? Amit hiányol
Várjon az éles környezetre Valódi hibák Minden, amíg egy felhasználó rá nem kattint
Mockold az API-t a tesztjeidben, vagy hagyd, hogy a kódolási ügynök megírja a mockot Hogy lefut-e az újrapróbálkozási ág GitHub valós fejléceit és hibatörzseit, valamint az SDK újrapróbálkozási szabályzatát. Az alkalmazásnak egy csak tesztelési kapcsolóra is szüksége van a mock eléréséhez.
Hívja meg a valódi API-t, amíg korlátozásba nem ütközik Valós viselkedés Akár 5000 kérést is felemészthet, nem válthat ki másodlagos korlátozást igény szerint, és fennáll a veszélye, hogy letilthatják az integrációját
Elfogja az alkalmazás valós forgalmát, és igény szerint visszaadja a sebességkorlátozási válaszokat Valós URL-címek, valódi SDK- és újrapróbálkozési szabályzat, valamint GitHub saját fejlécei és hibaformátuma Az alkalmazásban semmi sem változik, ezért nem teszteli a kódodat izoláltan. Arra valók az egységtesztek.

Próbálja ki az alkalmazásában

A Dev Proxy elfogja az alkalmazás kéréseitapi.github.com, és GitHub típusú sebességkorlát-válaszokat ad vissza, miközben az alkalmazás folyamatosan hívja a valódi URL-címeket. Az github-rate-limiting előbeállítás a kéréseidet óránkénti 60-as limitbe számítja bele, elküldi a x-ratelimit-* fejléceket, és egy API rate limit exceeded választ ad vissza 429 tartalommal, amikor kimeríted a keretet. Addig a kéréseid a GitHubhoz jutnak, és a valódi limitedbe is beleszámítanak.

Töltse le a beállításkészletet, és indítsa el vele a Dev Proxyt:

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

A másodlagos korlátok teszteléséhez indítsa el helyette a Dev Proxyt a devproxyrc-secondary.json ugyanabból a mappából. Véletlenszerűen egy másodlagos sebességkorlátozást 429 ad vissza egy retry-after fejléccel.

Ezután futtassa az alkalmazást a szokásos módon, és figyelje meg, hogy mit csinál. A Dev Proxy telepítéséhez lásd: Dev Proxy beállítása.

További lépések

Annak tesztelése, hogy az alkalmazás hogyan kezeli GitHub API-sebességkorlátokat

Lásd még

  • Utolsó frissítés időpontja: