GitHub batas laju API terlampaui: apa artinya dan cara menanganinya

GitHub membatasi berapa banyak permintaan REST API yang dapat dikirim aplikasi Anda. Saat Anda melewati batas, GitHub menolak permintaan Anda dengan status 403 atau 429 hingga batas diatur ulang atau waktu tunggu berlalu. GitHub memiliki 2 jenis batas: batas utama pada permintaan per jam, dan batas sekunder yang melindungi dari lonjakan. Jika aplikasi Anda terus mengirim permintaan saat dikenai pembatasan laju, GitHub dapat melarang integrasi Anda. Untuk informasi selengkapnya, lihat Batas laju untuk REST API.

Seperti apa batas laju GitHub terlihat

Limit Value Saat Anda meninjaunya
Utama, tidak terautentikasi 60 permintaan per jam, per alamat IP 403 atau 429, dan x-ratelimit-remaining adalah 0
Token akses utama, pribadi 5.000 permintaan per jam Sama seperti di atas
Utama, GITHUB_TOKEN dalam GitHub Actions 1.000 permintaan per jam, per repositori Sama seperti di atas
Secondary Misalnya, tidak lebih dari 100 permintaan bersamaan, 900 poin per menit untuk titik akhir REST, dan sekitar 80 permintaan pembuatan konten per menit 403 atau 429 dengan pesan kesalahan. retry-after mungkin ada.

GitHub dapat mengubah batas sekunder tanpa pemberitahuan, dan tidak ada cara untuk memeriksa seberapa dekat Anda dengan batas tersebut.

Setiap respons menyertakan header yang memberi tahu Anda di mana Anda berdiri pada batas utama:

Header Apa yang diberitahukannya
x-ratelimit-limit Jumlah permintaan maksimum yang dapat Anda kirim per jam
x-ratelimit-remaining Berapa banyak permintaan yang tersisa di jendela saat ini
x-ratelimit-used Berapa banyak permintaan yang Anda kirim di periode saat ini
x-ratelimit-reset Saat jendela direset, dalam detik epoch UTC
x-ratelimit-resource Batas yang digunakan untuk menghitung permintaan ini

Cara menangani batas laju GitHub

  1. Bedakan batas laju dari kesalahan izin. GitHub juga mengembalikan 403 saat token Anda tidak memiliki akses. Jika respons tidak memiliki retry-after, x-ratelimit-remaining bukan 0, dan pesan tidak menyebutkan batas tarif, itu adalah masalah izin. Jangan coba ulang.
  2. Ikuti retry-after dulu. Jika header ada, tunggu selama jumlah detik tersebut.
  3. Jika tidak, tunggu reset. Jika x-ratelimit-remaining adalah 0, jangan coba lagi sampai waktu di x-ratelimit-reset.
  4. Jika tidak, tunggu setidaknya 1 menit. Untuk batas sekunder tanpa kedua header tersebut, GitHub meminta Anda untuk menunggu setidaknya 1 menit dan menunggu lebih lama setelah setiap percobaan ulang yang gagal. Berhenti setelah sejumlah percobaan ulang yang ditetapkan dan munculkan kesalahan.
  5. Pelan-pelan sebelum Anda kehabisan. Gunakan x-ratelimit-remaining dan x-ratelimit-reset untuk mengatur laju permintaan Anda. Jangan membangun logika di sekitar jumlah sisa yang persis, karena GitHub dapat mengubah batas. Header x-ratelimit-* adalah sumber kebenaran, bukan GET /rate_limit titik akhir.
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;
}

Penelepon Anda mencoba kembali saat fungsi mengembalikan angka, dan berhenti setelah beberapa upaya.

Cara menguji bahwa aplikasi Anda menangani batas laju GitHub

Anda jarang mencapai rate limit GitHub saat Anda mengembangkan. Anda mengirim beberapa permintaan, dan 5.000 per jam terasa tidak ada habisnya. Jadi cara Anda menguji penanganan rate limit memutuskan apakah Anda menemukan bug sebelum pengguna Anda melakukannya.

Approach Apa yang Anda temukan Yang Anda lewatkan
Tunggu hingga produksi siap Kegagalan aktual Semuanya, sampai pengguna menekannya
Mock API dalam pengujian Anda, atau biarkan agen pengkodan Anda menulis mock Apakah cabang percobaan ulang Anda berjalan Header asli GitHub dan isi body error, serta kebijakan retry SDK Anda. Aplikasi Anda juga memerlukan sakelar khusus pengujian untuk mengakses mock.
Panggil API nyata hingga API tersebut membatasi Anda Perilaku sebenarnya Dibutuhkan hingga 5.000 permintaan, Anda tidak dapat memicu batas sekunder sesuai permintaan, dan integrasi Anda berisiko diblokir
Mencegat lalu lintas nyata aplikasi Anda dan mengembalikan respons pembatasan laju sesuai permintaan URL nyata, SDK nyata Anda dan kebijakan percobaan ulang, serta header dan format kesalahan GitHub sendiri Tidak ada perubahan dalam aplikasi Anda, sehingga tidak menguji kode Anda dalam isolasi. Gunakan unit test untuk itu.

Coba ini di aplikasi Anda

Dev Proxy mencegat permintaan aplikasi Anda ke api.github.com dan mengembalikan respons batas laju gaya GitHub, sementara aplikasi Anda terus memanggil URL nyata. github-rate-limiting preset menghitung permintaan Anda terhadap batas 60 per jam, mengirim header x-ratelimit-*, dan mengembalikan 429 dengan API rate limit exceeded saat Anda kehabisan. Sampai saat itu, permintaan Anda masuk ke GitHub dan juga dihitung terhadap batas Anda yang sebenarnya.

Unduh preset, dan mulai Dev Proxy dengannya:

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

Untuk menguji batas sekunder, mulai Dev Proxy dengan devproxyrc-secondary.json dari folder yang sama sebagai gantinya. Ini secara acak menghasilkan batas tarif sekunder dengan header retry-after429

Kemudian jalankan aplikasi Anda seperti biasa dan tonton apa yang dilakukannya. Untuk menginstal Dev Proxy, lihat Menyiapkan Dev Proxy.

Langkah berikutnya

Uji cara aplikasi Anda menangani batas laju API GitHub

Baca juga

  • Terakhir diperbarui pada