Límite de peticiones de la API de GitHub superado: lo que significa y cómo gestionarlo

GitHub limita el número de solicitudes de API REST que puede enviar tu aplicación. Cuando se supera un límite, GitHub rechaza tus solicitudes con un estado 403 o 429 hasta que se restablezca el límite o transcurra el tiempo de espera. GitHub tiene dos tipos de límites: un límite principal en las solicitudes por hora y los límites secundarios que protegen contra las ráfagas. Si tu aplicación sigue enviando solicitudes mientras está sujeta a la limitación de tasa, GitHub podría bloquear tu integración. Para más información, consulte Límites de tasa para la API REST.

Cómo son las limitaciones de tasa de GitHub

GitHub puede cambiar los límites secundarios sin previo aviso y no hay ninguna manera de comprobar lo cerca que estás de alcanzarlos.

Cada respuesta incluye encabezados que indican cuál es su situación respecto del límite principal:

Cómo administrar un límite de frecuencia de GitHub

1. Distinguir un límite de frecuencia de un error de permiso. GitHub también devuelve 403 cuando el token no tiene acceso. Si la respuesta no tiene retry-after, x-ratelimit-remaining no es 0 y el mensaje no menciona un límite de peticiones, se trata de un problema de permisos. No vuelvas a intentarlo.
2. Siga retry-after primero. Si el encabezado está presente, espere esa cantidad de segundos.
3. De lo contrario, espere al reinicio. Si x-ratelimit-remaining es 0, no vuelva a intentarlo hasta el momento en x-ratelimit-reset.
4. De lo contrario, espere al menos 1 minuto. En el caso de un límite secundario sin ninguno de los dos encabezados, GitHub te pide que esperes al menos 1 minuto y que esperes más tiempo tras cada reintento fallido. Detenga después de un número establecido de reintentos y genere un error.
5. Ralentice antes de que se agote. Use x-ratelimit-remaining y x-ratelimit-reset para dosificar sus solicitudes. No cree lógica en torno a un recuento restante exacto, ya que GitHub puede cambiar los límites. Los x-ratelimit-* encabezados son la fuente de referencia, no el 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;
}

El código que llama vuelve a intentarlo cuando la función devuelve un número y se detiene después de algunos intentos.

Cómo probar que la aplicación controla los límites de tasa de GitHub

Rara vez alcanzas un límite de tasa de GitHub mientras desarrollas. Envías algunas solicitudes y 5.000 por hora parecen infinitas. Por lo tanto, la forma de probar la gestión de la limitación de tasa determina si encuentras los errores antes de que tus usuarios lo hagan.

Pruébalo en tu app

Dev Proxy intercepta las solicitudes de tu aplicación a api.github.com y devuelve respuestas de limitación de tasa al estilo de GitHub, mientras tu aplicación sigue llamando a las URL reales. El github-rate-limiting preajuste cuenta tus solicitudes con respecto a un límite de 60 por hora, envía los encabezados x-ratelimit-* y devuelve un 429 con API rate limit exceeded cuando se agota el límite. Hasta entonces, tus solicitudes se envían a GitHub y también cuentan para tu límite real.

Descargue el preajuste e inicie Dev Proxy con él:

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

Para probar los límites secundarios, inicie Dev Proxy con devproxyrc-secondary.json desde la misma carpeta en su lugar. Devuelve aleatoriamente un límite 429 de tasa secundario con la cabecera retry-after.

A continuación, ejecute la aplicación como de costumbre y observe lo que hace. Para instalar Dev Proxy, consulte Configurar Dev Proxy.

Pasos siguientes

Consulte también

• 429 Demasiadas solicitudes: lo que significa y cómo controlarlo
• Encabezado Retry-After: cuánto tiempo debe esperar antes de volver a intentarlo
• ¿Qué es la limitación de velocidad?
• Cómo controlar la limitación de velocidad
• Simula respuestas de la API con límite de tasa
• RateLimitingPlugin