Limite de taux de l’API GitHub dépassée : ce que cela signifie et comment la gérer

GitHub limite le nombre de demandes d’API REST que votre application peut envoyer. Lorsque vous dépassez une limite, GitHub rejette vos requêtes avec un statut 403 ou 429 jusqu’à ce que la limite soit réinitialisée ou que le temps d’attente passe. GitHub a 2 types de limites : une limite principale du nombre de requêtes par heure et des limites secondaires qui protègent contre les pics d’activité. Si votre application continue d'envoyer des demandes alors qu'elle est soumise à une limitation de débit, GitHub peut interdire votre intégration. Pour plus d’informations, consultez Les limites de débit pour l’API REST.

À quoi ressemblent les limites de taux de GitHub

Limit Value Lorsque vous le parcourez
Principal, non authentifié 60 requêtes par heure, par adresse IP 403 ou 429, et x-ratelimit-remaining est 0
Principal, jeton d’accès personnel 5 000 requêtes par heure Comme ci-dessus
Par défaut, GITHUB_TOKEN dans GitHub Actions 1 000 requêtes par heure, par dépôt Comme ci-dessus
Secondary Par exemple, pas plus de 100 requêtes simultanées, 900 points par minute pour les points de terminaison REST et environ 80 requêtes de génération de contenu par minute 403 ou 429 avec un message d’erreur. retry-after peut être présent.

GitHub peut modifier les limites secondaires sans préavis, et il n'existe aucun moyen de vérifier la proximité de celles-ci.

Chaque réponse inclut des en-têtes qui vous indiquent où vous vous trouvez sur la limite principale :

Header Ce qu’il vous dit
x-ratelimit-limit Le nombre maximal de requêtes que vous pouvez envoyer par heure
x-ratelimit-remaining Nombre de demandes qu'il vous reste dans la fenêtre active
x-ratelimit-used Nombre de demandes que vous avez envoyées dans la fenêtre actuelle
x-ratelimit-reset Lorsque la fenêtre est réinitialisée, en secondes d’époque UTC
x-ratelimit-resource Limite à laquelle la demande est comptabilisée

Comment gérer une limite de taux de GitHub

  1. Distinguez une limite de débit d’une erreur d’autorisation. GitHub retourne également 403 lorsque votre jeton ne dispose pas des droits d’accès. Si la réponse n’a pas retry-after, x-ratelimit-remaining n’est pas 0, et que le message ne mentionne pas de limitation du nombre de requêtes, il s’agit d’un problème d’autorisation. Ne réessayez pas.
  2. Suivez retry-after d’abord. Si l’en-tête est présent, attendez ce nombre de secondes.
  3. Sinon, attendez la réinitialisation. Si x-ratelimit-remaining est 0, ne réessayez pas avant l’heure indiquée dans x-ratelimit-reset.
  4. Sinon, attendez au moins 1 minute. Pour une limite secondaire sans en-tête, GitHub vous demande d’attendre au moins 1 minute et d’attendre plus longtemps après chaque nouvelle tentative ayant échoué. Arrêtez après un nombre défini de nouvelles tentatives et générez une erreur.
  5. Ralentissez avant d’épuiser votre quota. Utilisez x-ratelimit-reset et x-ratelimit-remaining pour réguler vos requêtes. Ne fondez pas votre logique sur un nombre exact restant, car GitHub peut modifier les limites. Les x-ratelimit-* en-têtes sont la source de vérité, et non le GET /rate_limit endpoint.
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;
}

Votre appelant réessaye lorsque la fonction retourne un nombre et s’arrête après quelques tentatives.

Comment tester que votre application gère les limites de taux de GitHub

Vous atteignez rarement une limite de requêtes GitHub pendant que vous développez. Vous envoyez quelques demandes, et 5 000 par heure semblent illimitées. Ainsi, la façon dont vous testez la gestion des limites de débit détermine si vous trouvez les bogues avant que vos utilisateurs ne le fassent.

Approach Ce que vous trouvez Ce qui vous manque
Attendre la mise en production Échecs réels Tout, jusqu’à ce qu’un utilisateur appuie dessus
Simuler l’API dans vos tests ou laisser votre agent de codage écrire la simulation Si votre branche de nouvelle tentative s’exécute les en-têtes réels de GitHub et les corps d’erreur, ainsi que la stratégie de nouvelle tentative de votre kit de développement logiciel (SDK). Votre application a également besoin d’un commutateur de test uniquement pour atteindre la simulation.
Appelez l’API réelle jusqu’à ce qu’elle vous limite Comportement réel Il faut jusqu’à 5 000 demandes, vous ne pouvez pas déclencher une limite secondaire à la demande et vous risquez une interdiction de votre intégration
Interceptez le trafic réel de votre application et renvoyez des réponses de limitation de débit à la demande URL réelles, votre véritable sdk et stratégie de nouvelle tentative, ainsi que les en-têtes propres à GitHub et son format d’erreur Rien dans votre application ne change, cela ne teste donc pas votre code de manière isolée. Conservez vos tests unitaires pour cela.

Essayez-le sur votre application

Dev Proxy intercepte les requêtes de votre application vers api.github.com et renvoie des réponses de limitation du débit de style GitHub, tandis que votre application continue d’appeler les URL réelles. La github-rate-limiting présélection compte vos requêtes par rapport à une limite de 60 par heure, envoie les x-ratelimit-* en-têtes et retourne une 429 valeur avec API rate limit exceeded quand vous expirez. Jusqu’à ce moment- là, vos demandes vont à GitHub et comptent contre votre limite réelle aussi.

Téléchargez le preset et démarrez Dev Proxy avec celui-ci :

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

Pour tester les limites secondaires, démarrez Dev Proxy avec devproxyrc-secondary.json depuis le même dossier à la place. Elle retourne de façon aléatoire une limite 429 de débit secondaire avec un retry-after en-tête.

Exécutez ensuite votre application comme d’habitude et regardez ce qu’elle fait. Pour installer Dev Proxy, consultez Configurer Dev Proxy.

Étapes suivantes

Testez la façon dont votre application gère les limites de débit d’API GitHub

Voir aussi

  • Dernière mise à jour :