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. Al superar un límite, GitHub rechaza las solicitudes con estado 403 o 429 hasta que se restablece el límite o se agota 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 la aplicación sigue enviando solicitudes mientras se le aplica una limitación de tasa, GitHub puede prohibir la integración. Para más información, consulte Límites de tasa para la API REST.

Qué aspecto tienen los límites de tasa de GitHub

Limit Value Cuando lo revises
Principal, no autenticado 60 solicitudes por hora, por dirección IP 403 o 429, y x-ratelimit-remaining es 0
Token de acceso personal principal 5000 solicitudes por hora Igual que en el caso anterior
Primario, GITHUB_TOKEN en Acciones de GitHub 1000 solicitudes por hora, por repositorio Igual que en el caso anterior
Secundaria Por ejemplo, no más de 100 solicitudes simultáneas, 900 puntos por minuto para los puntos de conexión REST y aproximadamente 80 solicitudes de generación de contenido por minuto 403 o 429 con un mensaje de error. retry-after podría estar presente.

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:

Header Lo que te dice
x-ratelimit-limit El número máximo de solicitudes que puede enviar por hora
x-ratelimit-remaining Cuántas solicitudes le quedan en la ventana actual
x-ratelimit-used ¿Cuántas solicitudes envió en la ventana de tiempo actual?
x-ratelimit-reset Cuando se restablece la ventana, en segundos de época UTC
x-ratelimit-resource Qué límite se aplica a la solicitud contabilizada

Cómo controlar un límite de solicitudes de GitHub

  1. Distinga un límite de tasa de un error de permisos. 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. Para un límite secundario sin ningún encabezado, GitHub le pide que espere al menos 1 minuto y espere más tiempo después de 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.

Approach Lo que encuentras Lo que te pierdes
Esperar la salida a producción Fallos reales Todo, hasta que un usuario haga clic en ello
Simula la API en tus pruebas o deja que el agente de codificación escriba el simulacro Si la rama de reintento se ejecuta Los encabezados reales y los cuerpos de error de GitHub, y la directiva de reintento de tu SDK. La aplicación también necesita una opción solo para pruebas para llegar al mock.
Llame a la API real hasta que la API le aplique un límite. Comportamiento real Se necesitan hasta 5.000 solicitudes, no se puede activar un límite secundario a voluntad y se corre el riesgo del bloqueo de tu integración.
Interceptar el tráfico real de la aplicación y devolver respuestas de limitación de tasa bajo demanda Direcciones URL reales, el SDK real y la directiva de reintento, y los propios encabezados de GitHub y el formato de error Nada en la aplicación cambia, por lo que no prueba el código de forma aislada. Mantenga las pruebas unitarias para eso.

Pruébalo en tu app

El proxy de desarrollo intercepta las solicitudes de la aplicación a api.github.com y devuelve respuestas de limitación de tasa al estilo de GitHub, mientras que la aplicación sigue llamando a las direcciones URL reales. El github-rate-limiting valor preestablecido cuenta tus solicitudes para un límite de 60 por hora, envía los x-ratelimit-* encabezados y devuelve un 429 con API rate limit exceeded cuando agotas el límite. Hasta entonces, las solicitudes van 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

Prueba cómo controla la aplicación los límites de solicitudes de la API de GitHub

Consulte también

  • Se actualizó por última vez el