Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

GitHub.searchIssues fails with 422 when perPage does not evenly divide the 1000-result cap

Abierto Apto para principiantes
  • ¿Algo no está bien?
#56 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
82/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
api

Línea de trabajo

Comienza en src/prompt-generators/github/github.ts e inspecciona el bucle de paginación de searchIssues, junto con normalizeMaxResults y GITHUB_SEARCH_RESULT_LIMIT. Reproduce el problema con perPage: 70 y una consulta que supere los 1.000 resultados, y verifica que la paginación se detenga antes de realizar una solicitud cuyo intervalo de página exceda el límite sin lanzar un error 422.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug S3

Observed behavior

GitHub.searchIssues throws GitHub API error 422: Only the first 1000 search results are available when perPage is set to a value that does not evenly divide 1000 and the underlying query has more than 1000 matching issues.

GitHub's REST search API has a hard cap of 1,000 results per query, and any request where page * per_page > 1000 is rejected with HTTP 422. normalizeMaxResults caps the effective maximum at GITHUB_SEARCH_RESULT_LIMIT (1000), and the pagination loop in searchIssues continues until issues.length >= maxResults. With a non-divisor perPage value, the loop reaches a page where page * perPage overshoots 1000 before issues.length reaches 1000.

Example with perPage: 70 and the default maxResults of 1000 against a query that returns 5000+ issues:

  • Pages 1 to 14 return 70 items each, accumulating 980 issues.
  • The break conditions at the end of page 14 are all false (items.length (70) < perPage (70) is false, 980 < total_count is true, 980 < 1000 is true), so the loop continues.
  • Page 15 is requested with per_page=70, so 15 * 70 = 1050 > 1000. GitHub returns HTTP 422 and searchIssues throws.

This is silent at the type/config level: the docstring on GitHubIssueSearchParams.perPage says "GitHub accepts 1 to 100" with no caveat about result-window alignment.

Expected behavior

searchIssues should not crash with a 422 when used within the documented perPage and maxResults contracts. It should either stop paginating once the next request would overshoot the 1000-result window, or normalize perPage so that it always evenly divides the effective cap.

Minimal reproduction

import { GitHub } from 'loop-the-loop/prompt-generators/github/github';
import { vi } from 'vitest';

vi.stubGlobal(
  'fetch',
  vi.fn().mockImplementation((url: string) => {
    const u = new URL(url);
    const page = Number(u.searchParams.get('page'));
    const perPage = Number(u.searchParams.get('per_page'));
    if (page * perPage > 1000) {
      return Promise.resolve({
        ok: false,
        status: 422,
        text: () =>
          Promise.resolve(
            JSON.stringify({
              message: 'Only the first 1000 search results are available',
            }),
          ),
      });
    }
    return Promise.resolve({
      ok: true,
      status: 200,
      text: () =>
        Promise.resolve(
          JSON.stringify({
            total_count: 5000,
            items: Array.from({ length: perPage }, (_v, i) => ({
              number: (page - 1) * perPage + i + 1,
              title: 't',
              html_url: 'https://github.test/x',
              state: 'open',
            })),
          }),
        ),
    });
  }),
);

const github = new GitHub({ origin: 'https://api.test' });
await github.searchIssues({
  repository: 'octocat/Hello-World',
  query: 'is:open',
  perPage: 70,
});
// throws: GitHub API error 422: Only the first 1000 search results are available

Suggested fix

In the pagination loop in src/prompt-generators/github/github.ts, stop iterating once the next request would push past the result window. For example, extend the post-page break to also handle the cap:

if (
  reply.items.length < perPage ||
  issues.length >= reply.total_count ||
  issues.length >= maxResults ||
  (page + 1) * perPage > GITHUB_SEARCH_RESULT_LIMIT
) {
  break;
}

Alternatively, normalize perPage so that it always divides maxResults (and therefore GITHUB_SEARCH_RESULT_LIMIT) cleanly when the cap is in effect, and document the rounding behavior on GitHubIssueSearchParams.perPage.

Lenguaje dominante
TypeScript
Estrellas
2
Forks
1
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de joewalker/loop-the-loop

Todos los issues de joewalker/loop-the-loop

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.