GitHub.searchIssues silently drops 'incomplete_results: true' from search responses
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 68/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- typescript
- Área
- api
Línea de trabajo
Start in src/prompt-generators/github/github.ts and trace the #query calls used by searchIssues, then run the minimal reproduction against the mocked GitHub response. Decide how the existing caller contract should surface incomplete_results and verify that a true flag on any page is no longer silent.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Observed behavior
The GitHub search API can respond with incomplete_results: true in its JSON body. From the GitHub docs:
The Search API has a maximum query timeout of 5 seconds and a maximum result set of 1000. The
incomplete_resultsfield will betruewhenever a response is returned before the timeout completes, and indicates that some results may be missing.
GitHubSearchReply already types this field:
export interface GitHubSearchReply {
readonly total_count: number;
readonly incomplete_results?: boolean;
readonly items: ReadonlyArray<GitHubIssue>;
}
However, GitHub.searchIssues in src/prompt-generators/github/github.ts never reads incomplete_results. When the field is true, the caller receives a ReadonlyArray<GitHubIssue> that silently omits matches, with no indication that the result is partial. The downstream GitHubPromptGenerator then yields prompts only for the partial set as if it were the full result. This matches the S1 description ("a consumer using the library according to its documented contract receives a result that is wrong, with no error or warning to indicate the problem") at the boundary, but in practice the failure mode is intermittent and recovers on retry, so it is in S3 territory.
Expected behavior
searchIssues should surface incomplete_results: true to the caller in some form. Reasonable options:
- Log a warning to
stderrwhen the flag is observed on any page, similar tologQuery. - Throw an error, requiring the caller to opt in to incomplete results.
- Return a richer result object (
{ issues, incomplete }) instead of a bare array.
A console warning is the lowest-friction fix and matches the existing logging style; an opt-in flag (for example, allowIncomplete) would be more rigorous and avoid silent partial results by default.
Minimal reproduction
import { GitHub } from 'loop-the-loop/prompt-generators/github/github';
import { vi } from 'vitest';
vi.stubGlobal(
'fetch',
vi.fn().mockResolvedValue({
ok: true,
status: 200,
text: () =>
Promise.resolve(
JSON.stringify({
total_count: 12345,
incomplete_results: true,
items: [
{ number: 1, title: 't', html_url: 'https://github.test/1', state: 'open' },
],
}),
),
}),
);
const github = new GitHub({ origin: 'https://api.test' });
const issues = await github.searchIssues({
repository: 'octocat/Hello-World',
query: 'is:open',
perPage: 1,
maxResults: 1,
});
// issues.length === 1, but the caller has no way to know the search was
// truncated by GitHub's 5-second timeout.
Suggested fix
At minimum, in src/prompt-generators/github/github.ts, check reply.incomplete_results after each #query call and emit a console.warn (or expose the flag through the return type). For example:
if (reply.incomplete_results) {
console.warn(
`GitHub search returned incomplete results for query: ${buildIssueSearchQuery(params)}`,
);
}
- Lenguaje dominante
- TypeScript
- Estrellas
- 2
- Forks
- 1
- Métricas de merge de PR
- 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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de joewalker/loop-the-loop
-
bug S4
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
joewalker/loop-the-loop#88 ·
-
Git exec(): child killed by a signal rejects with new Error('') and loses the signal informationAbiertobug S3
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
joewalker/loop-the-loop#84 ·
-
bug S3
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
joewalker/loop-the-loop#83 ·
-
bug S3
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
joewalker/loop-the-loop#82 ·
-
bug S4
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
joewalker/loop-the-loop#79 ·
Todos los issues de joewalker/loop-the-loop
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
TomerAberbach/profiler-md#733 ·
Los mantenedores suelen responder en 1 día
-
bug priority: medium
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
brentspine/brents-toasts#143 ·
-
🐛 bug 🗺️ DB Models & Ops
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
LibreChat-AI/LibreChat#17214 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Wavvon/Wavvon-clients#136 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
umami-software/umami#4637 ·
Los mantenedores suelen responder en 3 días