Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

GitHub App token fallback misses recent issues in large repositories

オープン
  • 何か問題がありますか？
#83 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

@blalor がすでに取り組んでいます。

2026年8月20日 から。

  • #84 @blalor による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
github, github-actions, typescript
領域
api, ci-cd, devtools

調査の方向性

Github.matcher() と frog publish で使用される listAll() フォールバックから開始します。ラベル付き検索、権限処理、ページネーションの動作を追跡し、その後 issue に記載された 4 つのテストシナリオを実行します。完了とは、ラベル付きとラベルなしの両方の宛先について、繰り返しの publish によって一致するレポートと出現マーカーが重複排除され、大規模なリポジトリ内の最近の issue も対象になることです。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
267
フォーク
11
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

wevm/frog のほかの issue

wevm/frog の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。