Bug Report: Automated PR triage system incorrectly labeling all PRs with status/need-issue

[hoteye]

What happened?

Bug Description

The automated PR triage system is incorrectly applying the status/need-issue label to all open PRs, even when they have valid issue references in their descriptions.

Current Behavior

• All PRs in the repository currently have the status/need-issue label
• PRs with clear issue references (like "Addresses: Add internationalization (i18n) support to Gemini CLI #6525") are still being labeled as needing issues
• The triage system runs every 15 minutes and continuously misapplies these labels

What did you expect to happen?

Expected Behavior

PRs that reference valid GitHub issues should not have the status/need-issue label applied.

Client information

Root Cause

The triage script in .github/scripts/pr-triage.sh only checks GitHub's closingIssuesReferences API field:

gh pr view "${PR_NUMBER}" --json closingIssuesReferences -q '.closingIssuesReferences.nodes[0].number'

This API field only populates when PRs use specific GitHub closing keywords:

• Closes Isolate onSelect/onHighlight actions within AuthDialog #1234
• Fixes Isolate onSelect/onHighlight actions within AuthDialog #1234
• Resolves Isolate onSelect/onHighlight actions within AuthDialog #1234

But it ignores other valid reference formats:

• Addresses: Add internationalization (i18n) support to Gemini CLI #6525
• Related to Isolate onSelect/onHighlight actions within AuthDialog #1234
• See Isolate onSelect/onHighlight actions within AuthDialog #1234
• Manual issue links like [#6525](https://github.com/google-gemini/gemini-cli/issues/6525)

Examples of Incorrectly Labeled PRs

• PR feat(i18n): Phase 1 - Extract strings + i18next foundation #8060: Clearly states "Addresses: Add internationalization (i18n) support to Gemini CLI #6525" but has status/need-issue label
• Multiple other PRs have issue references but don't use exact closing keywords

Suggested Solutions

Short-term fix:

Update the triage script to also parse PR descriptions for issue number patterns (#\d+)

Long-term fix:

1. Update PR templates to require "Closes #XXXX" format
2. Add documentation about proper issue linking syntax
3. Consider using regex parsing as fallback when closingIssuesReferences is empty

Login information

No response

Anything else we need to know?

Immediate action:

Consider manually removing incorrect status/need-issue labels from PRs that have valid issue references

Impact

• Blocks legitimate PRs from proper workflow
• Confuses contributors about whether their PRs are properly linked
• Makes it difficult to identify PRs that actually need issue links
• Potentially delays reviews and merges

Additional Context

This affects the entire contributor workflow and creates friction for both new and experienced contributors who are following reasonable issue-linking practices.

Labels

• kind/bug
• area/automation
• priority/p1 (affects all contributors)

[gemini-cli]

This is a high-priority bug report affecting the contribution workflow for all contributors. The automated PR triage system is malfunctioning, which hinders the PR review process.

[agmsb]

Thanks for filing this issue. Investigating & looking at the PR.

[jakemac53]

Note that this is happening for me even with Closes #<issue-number> I think its just not working at all (example)

[hoteye]

@jakemac53

You're absolutely right! We've confirmed through testing that the current PR triage script is completely broken.

Root Cause Verified

The official PR triage script at .github/scripts/pr-triage.sh tries to use a non-existent API field:

gh pr view "${PR_NUMBER}" --json closingIssuesReferences -q '.closingIssuesReferences.nodes[0].number'

But closingIssuesReferences doesn't exist in the GitHub CLI API. When we test it:

$ gh pr view 8531 --repo google-gemini/gemini-cli --json closingIssuesReferences
Unknown JSON field: "closingIssuesReferences"

Impact

This means every single PR gets the status/need-issue label because:

1. The API call always fails (field doesn't exist)
2. ISSUE_NUMBER is always empty
3. Script assumes no issue link exists

Even PRs with perfect "Closes #123" format are being mislabeled.

Solution

PR #8531 fixes this by adding proper text parsing as a fallback when the API fails:

• Detects "Fixes fix .env check #123", "Closes Update docs and tool description for read-many-files. #456", "Resolves keyboard shortcut to abort partial prompt #789" patterns
• Removes dependency on the broken API field
• Restores the PR description parsing that was accidentally removed

The current system-wide failure of issue detection confirms this fix is critical for the triage automation to work at all.