Limite de débit de l'API GitHub dépassée : ce que cela signifie et comment gérer cette situation

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 code d'état 403 ou 429 jusqu'à ce que la limite soit réinitialisée ou que le délai d'attente soit écoulé. GitHub applique deux types de limites : une limite principale sur le nombre de requêtes par heure et des limites secondaires qui protègent contre les pics de requêtes. Si votre application continue d'envoyer des requêtes alors qu'elle est soumise à une limitation de débit, GitHub peut bannir votre intégration. Pour plus d’informations, consultez Les limites de débit pour l’API REST.

Présentation des limites de débit de GitHub

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 :

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'atteindre votre limite. Utilisez x-ratelimit-remaining et x-ratelimit-reset pour réguler le rythme de vos requêtes. Ne fondez pas votre logique sur un nombre exact restant, car GitHub peut modifier les limites. Les en-têtes x-ratelimit-* font autorité, et non le point de terminaison GET /rate_limit.

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 requêtes, et une limite de 5 000 requêtes par heure semble inépuisable. 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.

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. Le préréglage github-rate-limiting comptabilise vos requêtes par rapport à une limite de 60 par heure, envoie les en-têtes x-ratelimit-* et renvoie un code 429 avec API rate limit exceeded lorsque vous atteignez la limite. Jusque-là, vos requêtes sont transmises à GitHub et sont également comptabilisées dans votre limite réelle.

Téléchargez le préréglage 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 plutôt Dev Proxy avec devproxyrc-secondary.json à partir du même dossier. Il renvoie de manière aléatoire une réponse de limitation de débit secondaire 429 avec un en-tête retry-after.

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

Étapes suivantes

Voir aussi

• 429 Too Many Requests : signification et gestion de cette erreur
• En-tête Retry-After : durée d’attente avant de réessayer
• Qu’est-ce que la limitation du taux ?
• Comment gérer la limitation du débit
• Simuler des réponses d'API de limitation de débit
• RateLimitingPlugin