Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

GitHub App token fallback misses recent issues in large repositories

Aperta
  • Qualcosa non va?
#83 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@blalor ci sta già lavorando.

Dal 20/8/2026.

  • #84 di @blalor — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
github, github-actions, typescript
Ambito
api, ci-cd, devtools

Direzione di ricerca

Inizia da Github.matcher() e dal fallback listAll() utilizzato da frog publish. Traccia la ricerca per etichetta, la gestione delle autorizzazioni e il comportamento della paginazione, quindi esegui i quattro scenari di test elencati nell’issue. Il lavoro è completato quando pubblicazioni ripetute deduplicano i report corrispondenti e i marker di occorrenza sia per le destinazioni con etichetta sia per quelle senza etichetta, incluse le issue recenti nei repository di grandi dimensioni.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
267
Fork
11
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di wevm/frog

Tutte le issue di wevm/frog

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.