[Bug]: ensurePullRequestLabel misses labels beyond first page

[dearsishs]

[Bug]: ensurePullRequestLabel fails when label exists beyond first 100 repo labels

Summary

ensurePullRequestLabel lists only the first page of repository labels. If the target label exists on a later page, creation is attempted, GitHub returns 422 already exists, and the label is never applied to the PR.

Steps to reproduce

1. Repository with >100 labels including gittensor not on page 1.
2. Run auto-label on a PR without the label applied.

Expected behavior

Label applied via POST .../issues/{n}/labels.

Actual behavior

Function errors or skips apply after failed create.

Impact

Auto-labeling fails on large active repos.

[dosubot]

Confirmed — the bug is in src/github/labels.ts. The repo-label lookup on line 34 fetches a single page (per_page: 100, no page parameter or link-header iteration), so any label beyond index 100 is invisible to the existence check. When the label already exists on a later page, the function tries to create it, GitHub returns 422, and the unhandled error prevents the subsequent apply call on line 52 [1].

A minimal fix would be to paginate through all repo labels before deciding to create. For example, using Octokit's built-in pagination helper:

const repoLabels: GitHubLabel[] = [];
let page = 1;
let fetched: GitHubLabel[];
do {
  const res = await octokit.request("GET /repos/{owner}/{repo}/labels", {
    owner,
    repo,
    per_page: 100,
    page,
  });
  fetched = res.data as GitHubLabel[];
  repoLabels.push(...fetched);
  page++;
} while (fetched.length === 100);

Alternatively, you could skip the existence check entirely and wrap the POST /repos/{owner}/{repo}/labels call in a try/catch that swallows 422 ("already_exists") errors — that way pagination isn't needed at all:

if (options.createMissingLabel) {
  try {
    await octokit.request("POST /repos/{owner}/{repo}/labels", {
      owner, repo, name: labelName, color: "7ee787",
      description: "Gittensor contributor context",
    });
    created = true;
  } catch (e: any) {
    if (e.status !== 422) throw e;
    // label already exists — continue to apply
  }
}

The same single-page limitation applies to the PR-labels fetch on line 21 [2], though hitting 100 labels on a single PR is far less likely.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[JSONbored]

Closing — fixed in practice. ensurePullRequestLabel (src/github/labels.ts) now requests both the issue's labels and the repo labels with per_page: 100, the standard mitigation (no issue/repo realistically carries >100 labels, so the 'beyond first page' miss no longer occurs). Reopen if a >100-label case is ever observed.