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

GitHub App token fallback misses recent issues in large repositories

Abierto
  • ¿Algo no está bien?
#83 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@blalor ya está trabajando en esto.

Desde el 20/8/2026.

  • #84 de @blalor — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
github, github-actions, typescript
Área
api, ci-cd, devtools

Línea de trabajo

Comienza en Github.matcher() y en el fallback listAll() utilizado por frog publish. Sigue la búsqueda etiquetada, la gestión de permisos y el comportamiento de paginación; después, ejecuta los cuatro escenarios de prueba enumerados en el issue. Se considera terminado cuando las publicaciones repetidas deduplican los informes coincidentes y los marcadores de ocurrencia tanto para destinos etiquetados como no etiquetados, incluidos los issues recientes en repositorios grandes.

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

Descripción

Expected Behavior

Repeated frog publish runs find an issue created by an earlier run when it has the configured friction label and identical report and occurrence markers.

This should work when an Action-only workflow passes a GitHub App installation token, as documented in Frog's Action-only instructions.

Current Behavior

With a GitHub App installation token, Github.matcher() can treat the repository as unlabelled even when the same token successfully creates an issue with the configured label.

The publish result then includes the repository in unlabelled. The fallback calls listAll(), which requests issues oldest-first and stops after 50 pages of 100. In a repository with more than 5,000 issues, it does not inspect recently created Frog issues. A later publish can therefore create another issue for the same report and occurrence markers.

Possible Solution

Build the label-filtered issue index regardless of repos.get().permissions.push. Reading issues by label does not require permission to apply that label.

Keep the permission result for warning whether labels are expected to stick. If the labelled lookup misses, scan the unlabelled fallback newest-first so its bounded lookup includes recent reports.

Tests should cover:

  • a token whose repository response does not indicate push permission while a matching labelled issue exists;
  • a recent matching issue outside the oldest 5,000 repository issues;
  • a destination where labels cannot be applied and the unlabelled fallback is required;
  • report and occurrence marker deduplication across these paths.

Minimal Reproducible Example

  1. Use Frog 1.1.0 with a GitHub App installation token in a repository containing more than 5,000 issues.
  2. Configure issue-author for the App bot and publish one unlinked entry.
  3. Confirm that the issue has the configured label while the publish result reports the destination as unlabelled.
  4. Run frog publish again before merging the generated issue: link.
  5. Observe a second issue with the same report and occurrence markers.

The workflow follows Frog's documented custom-token configuration: it passes the installation token as the action's token, sets issue-author to the App bot login, and uses the same login in the issue-event guard. actions/create-github-app-token inherits the installation permissions by default.

Context

This can repeatedly file the same friction entry while the generated frog/sync pull request waits to merge. Restricting workflow triggers reduces the window but does not make publishing idempotent.

Lenguaje dominante
TypeScript
Estrellas
267
Forks
11
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 wevm/frog

Todos los issues de wevm/frog

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.