GitHub API hız sınırı aşıldı: ne anlama gelir ve nasıl işlenir

GitHub, uygulamanızın gönderebileceği REST API isteklerini sınırlar. Bir sınırı aştığınızda, GitHub sınır sıfırlanıncaya veya bekleme süresi geçene kadar isteklerinizi 429 veya 403 durumu ile reddeder. GitHub 2 tür sınırı vardır: saatlik isteklerde birincil sınır ve ani artışlara karşı koruma sağlayan ikincil sınırlar. Uygulamanız hız sınırlamasındayken istek göndermeye devam ederse GitHub entegrasyonunuzu yasaklayabilir. Daha fazla bilgi için bkz. REST API için hız sınırları.

GitHub oran sınırları nasıldır?

Limit Value Üzerinden geçtiğinde
Birincil, kimliği doğrulanmamış Saatte 60 istek, IP adresi başına 403 veya 429 ve x-ratelimit-remaining0dır
Birincil, kişisel erişim belirteci Saatte 5.000 istek Yukarıdakiyle aynı
Birincil, GITHUB_TOKEN GitHub Actions içinde Depo başına saatte 1.000 istek Yukarıdakiyle aynı
Secondary Örneğin, en fazla 100 eşzamanlı istek, REST uç noktaları için dakikada 900 nokta ve dakikada yaklaşık 80 içerik oluşturma isteği 403 veya 429 bir hata iletisi gösterir. retry-after mevcut olabilir.

GitHub önceden bildirimde bulunmadan ikincil sınırları değiştirebilir ve bunlara ne kadar yakın olduğunuzu denetlemenin hiçbir yolu yoktur.

Her yanıt, birincil sınırda nerede durduğunızı belirten üst bilgiler içerir:

Header Size ne söyler?
x-ratelimit-limit Saatte gönderebileceğiniz en fazla istek sayısı
x-ratelimit-remaining Geçerli pencerede kaç isteğiniz kaldı?
x-ratelimit-used Geçerli pencerede kaç istek gönderdiniz?
x-ratelimit-reset Pencere sıfırlandığında, UTC epoch saniyesi cinsinden
x-ratelimit-resource İsteğin hangi limite sayıldığı

GitHub hız sınırıyla nasıl başa çıkılır

  1. Bir hız sınırını izin hatasından ayırt edin. GitHub ayrıca belirtecinizin erişimi olmadığında 403 da döndürür. Yanıtta retry-after yoksa, x-ratelimit-remaining0 değilse ve ileti bir hız sınırından bahsetmiyorsa, bu bir izin sorunudur. Bunu yeniden denemeyin.
  2. Önce retry-after takip edin. Üst bilgi varsa, üst bilgide belirtilen saniye kadar bekleyin.
  3. Aksi halde sıfırlama işlemini bekleyin. Eğer x-ratelimit-remaining0 ise, x-ratelimit-reset içindeki zamana kadar yeniden denemeyin.
  4. Aksi takdirde en az 1 dakika bekleyin. Her iki başlık da olmadan ikincil bir sınır için GitHub, en az 1 dakika beklemenizi ve başarısız olan her yeniden denemeden sonra daha uzun beklemenizi ister. Belirli sayıda yeniden denemeden sonra durdurun ve hata verin.
  5. Tükenmeden önce yavaşlayın. İsteklerinizi dengelemek için x-ratelimit-reset ve x-ratelimit-remaining kullanın. GitHub sınırları değiştirebileceğinden, kesin kalan sayıya göre mantık kurmayın. x-ratelimit-* başlıklar, GET /rate_limit uç nokta değil, gerçeğin kaynağıdır.
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ğıranınız, işlev bir sayı döndürdüğünde yeniden dener ve birkaç denemeden sonra durur.

Uygulamanızın GitHub hız sınırlarını işlediğini test etme

Geliştirirken nadiren GitHub istek sınırına takılırsınız. Birkaç istek gönderirsiniz ve saatte 5.000 istek sonsuz gibi görünür. Dolayısıyla oran sınırlama yönetimini test etme yönteminiz, hataları kullanıcılarınızdan önce bulup bulmayacağınız konusunda karar verir.

Approach Bulduklarınız Kaçırdıklarınız
Üretimi bekleyin Gerçek başarısızlıklar Bir kullanıcı ona tıklayana kadar her şey
Testlerinizde API'yi taklit edin veya kodlama aracınızın mock’u yazmasına izin verin Yeniden deneme dalınızın çalışıp çalışmadığı GitHub’ın gerçek üst bilgileri ve hata gövdeleri ile SDK’nızın yeniden deneme ilkesi. Uygulamanızın mock’a erişmek için ayrıca yalnızca teste özel bir anahtara da ihtiyacı vardır.
Sizi sınırlayana kadar gerçek API'yi çağırın Gerçekleşen davranış 5.000 isteğe kadar destekler, isteğe bağlı olarak ikincil bir sınır tetikleyemezsiniz ve tümleştirmenizin yasaklanması riskini alırsınız
Uygulamanızın gerçek trafiğini yakalayın ve istek üzerine oran sınırlama yanıtları döndürün Gerçek URL'ler, gerçek SDK'nız, yeniden deneme ilkeniz ve GitHub'ın kendi üstbilgileri ile hata biçimi Uygulamanızda hiçbir şey değişmez, bu nedenle kodunuz yalıtılmış olarak test edilmez. Bunun için birim testlerinizi ayırın.

Uygulamanızda deneyin

Dev Proxy, uygulamanız gerçek URL'leri çağırmaya devam ederken uygulamanızın api.github.com adresine yaptığı istekleri yakalar ve GitHub stilinde hız sınırı yanıtları döndürür. github-rate-limiting hazır ayarı, isteklerinizi saat başına 60 sınırına karşı sayar, x-ratelimit-* üst bilgilerini gönderir ve limitiniz tükendiğinde 429 içeren bir API rate limit exceeded döndürür. O zamana kadar istekleriniz GitHub’a gider ve gerçek sınırınıza karşı da sayılır.

Ön ayarı indirin ve Dev Proxy’yi bununla başlatın:

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

İkincil sınırları test etmek için, bunun yerine Dev Proxy'yi aynı klasörden devproxyrc-secondary.json ile başlatın. Rastgele olarak retry-after ikincil bir hız sınırı 429 üst bilgisiyle döndürür.

Ardından uygulamanızı her zamanki gibi çalıştırın ve ne yaptığını izleyin. Dev Proxy'yi yüklemek için Dev Proxy'yi ayarlama bölümüne bakın.

Sonraki Adımlar

Uygulamanızın GitHub API hız sınırlarını nasıl işlediğini test edin

Ayrıca bkz.

  • Last updated on